negative number evaluating greater than string.size()

[Jeff Schwab]

Re: negative number evaluating greater than string.size()

John Harrison wrote:[color=blue]
> "Gianni Mariani" <gi2nospam@mari ani.ws> wrote in message
> news:c12sm0$kkk @dispatch.conce ntric.net...
>[color=green]
>>Jason wrote:
>>[color=darkred]
>>>Hi, below is example code which demonstrates a problem I have encountered. When passing a number to a function I compare it with a string's size and then take certain actions, unfortunately during the testing of it I discovered that negative numbers were being treated as if they were > 0. I compiled the following on mingw compiler/dev c++/windows xp. If I replace string.size() for a ordinary number it behaves as expected? I
>>>notice string.size() returns size type and not an int but how do I deal with that? Thanks in advance for any help[/color][/color][/color]

<reinserted>

void something(int number) {
if(number < str.size()) { /*...*/ }
}

</>
[color=blue][color=green]
>>GCC sez:
>>
>>signed_probs. cpp: In function `void something(int)' :
>>signed_probs. cpp:17: warning: comparison between signed and unsigned
>>integer expressions
>>
>>Changing line 17 to :
>>
>> if(number < static_cast<int >(str.size()) ) { cout << " hello" << endl; }
>>
>>solves the problem.
>>[/color]
>
>
> Of course this is what the OP should do,[/color]

No, an unnecessary cast is not what the OP should do. The problem is
that a signed "number" is being compared to an unsigned "size." "int"
and "string::size_t ype" are not the same thing; they are not always
comparable. A more reasonable solution would be for "number" to be of
string::size_ty pe in the first place, or of a signed type that knows how
to compare itself with string::size_ty pe.

[Rolf Magnus]

Re: negative number evaluating greater than string.size()

lilburne wrote:
[color=blue]
> I think it was for the reasons of inadvertantly mixing
> signed and unsigned that Lakos recommended avoiding unsigned
> in interfaces in "Large Scale C++".[/color]

Same for Stroustup in TC++PL. Strange enough that size_t is unsinged,
since Stroustrup probably had to do something with it. In the book, he
writes:

"The unsigned integer types are ideal for uses that treat storage as a
bit array. Using an unsigned instead of an int to gain one more bit to
represent positive integers is almost never a good idea. Attempts to
ensure that some values are positive by declaring variables unsigned
will typically be defeated by the implicit conversion rules."

[lilburne]

Re: negative number evaluating greater than string.size()



Jeff Schwab wrote:
[color=blue]
>
> No, an unnecessary cast is not what the OP should do. The problem is
> that a signed "number" is being compared to an unsigned "size." "int"
> and "string::size_t ype" are not the same thing; they are not always
> comparable. A more reasonable solution would be for "number" to be of
> string::size_ty pe in the first place, or of a signed type that knows how
> to compare itself with string::size_ty pe.
>[/color]

Naturally! And std::vector::si ze_type, std::list::size _type,
std::deque::siz e_type, std::set::size_ type, std::map::size_ type, etc,
whenever dealing with the corresponding class. Maybe they'll all be the
same underlaying type, but who can tell?

[Jeff Schwab]

Re: negative number evaluating greater than string.size()

lilburne wrote:[color=blue]
>
>
> Jeff Schwab wrote:
>[color=green]
>>
>> No, an unnecessary cast is not what the OP should do. The problem is
>> that a signed "number" is being compared to an unsigned "size." "int"
>> and "string::size_t ype" are not the same thing; they are not always
>> comparable. A more reasonable solution would be for "number" to be of
>> string::size_ty pe in the first place, or of a signed type that knows
>> how to compare itself with string::size_ty pe.
>>[/color]
>
> Naturally! And std::vector::si ze_type, std::list::size _type,
> std::deque::siz e_type, std::set::size_ type, std::map::size_ type, etc,
> whenever dealing with the corresponding class.[/color]

That's right.
[color=blue]
> Maybe they'll all be the
> same underlaying type, but who can tell?[/color]

A specialized template can.

[Rolf Magnus]

Re: negative number evaluating greater than string.size()

Andrey Tarasevich wrote:
[color=blue]
> John Harrison wrote:[color=green][color=darkred]
>>> ...
>>> Changing line 17 to :
>>>
>>> if(number < static_cast<int >(str.size()) ) { cout << " hello" <<
>>> endl; }
>>>
>>> solves the problem.
>>>[/color]
>>
>> Of course this is what the OP should do, but notice that the solution
>> effectively rules out strings where size() > INT_MAX. So why design
>> for such strings in the first place? Why not have size() return an
>> int? ...[/color]
>
> In my opinion, using a signed type to store an unsigned quantity is a
> low-level design error.[/color]

In mine, it's a design error to use an unsigned type if you don't have a
very good reason to do so. That you only want to store non-negative
values is not such a reason.
Why is there no unsigned floating point type, just for the case you want
to store only postive values?

[Andrey Tarasevich]

Re: negative number evaluating greater than string.size()

Rolf Magnus wrote:[color=blue][color=green]
>> ...
>> In my opinion, using a signed type to store an unsigned quantity is a
>> low-level design error.[/color]
>
> In mine, it's a design error to use an unsigned type if you don't have a
> very good reason to do so. That you only want to store non-negative
> values is not such a reason.[/color]

Well, looks like we have different opinions on the subject.
[color=blue]
> Why is there no unsigned floating point type, just for the case you want
> to store only postive values?[/color]

For several reasons. It is much more difficult to provide
implementation-level support for an additional floating-point type than
for an additional integral type in situations when the underlying
hardware does not support it. Additionally, aside from purely conceptual
reasons, there is very little benefit from one extra mantissa (or
exponent) bit in a floating-point type. Under these circumstances, since
most hardware does not provide support for unsigned floating-point
types, it is not reasonable to force these types into language.

BTW, the reasons for domination of signed integral types in certain
arithmetical contexts in C (inherited into C++, like integral promotions
from smaller types) are probably very similar.

--
Best regards,
Andrey Tarasevich

[Jorge Rivera]

Re: negative number evaluating greater than string.size()

>[color=blue]
> Suggest you read the recent thread 'time to get rid of unsigned?', started
> on 17/02/04.
>
> john
>
>[/color]

I read all the whining about unsigned, and still disagree....

Regardless, what sense does it make to have a string with size < 0?
Furthermore, he should have been using
void something(std:: string::size_ty pe)
to start with.

In my mind, this is just a problem of people not reading the standard
documentation.

The least programmers should do is see the header files to understand
what types are being used, not just trust their instincts.

[John Harrison]

Re: negative number evaluating greater than string.size()


"Jorge Rivera" <jorgeri@roches ter.rr.com> wrote in message
news:1NxZb.3323 3$um1.16156@twi ster.nyroc.rr.c om...[color=blue][color=green]
> >
> > Suggest you read the recent thread 'time to get rid of unsigned?',[/color][/color]
started[color=blue][color=green]
> > on 17/02/04.
> >
> > john
> >
> >[/color]
>
> I read all the whining about unsigned, and still disagree....
>
> Regardless, what sense does it make to have a string with size < 0?[/color]

That's not the point. Apparaently both Stroustrup and Lakos recomend
avoiding using unsigned for the size of something because of the potential
overflow problems, particularly (in my view) when one unsigned quantity has
to be subtracted from another.
[color=blue]
> Furthermore, he should have been using
> void something(std:: string::size_ty pe)
> to start with.[/color]

Maybe but you cannot know the problem he was working on.
[color=blue]
>
> In my mind, this is just a problem of people not reading the standard
> documentation.
>
> The least programmers should do is see the header files to understand
> what types are being used, not just trust their instincts.
>[/color]

Can't disagree with that.

john

[Gavin Deane]

Re: negative number evaluating greater than string.size()

Andrey Tarasevich <andreytarasevi ch@hotmail.com> wrote in message news:<103aju96l q2lkf2@news.sup ernews.com>...[color=blue]
> John Harrison wrote:[color=green][color=darkred]
> >> ...
> >> Changing line 17 to :
> >>
> >> if(number < static_cast<int >(str.size()) ) { cout << " hello" << endl; }
> >>
> >> solves the problem.
> >>[/color]
> >
> > Of course this is what the OP should do, but notice that the solution
> > effectively rules out strings where size() > INT_MAX. So why design for such
> > strings in the first place? Why not have size() return an int?
> > ...[/color]
>
> In my opinion, using a signed type to store an unsigned quantity is a
> low-level design error.[/color]

What does unsigned gain you? If you use signed and write code with a
bug, you could end up calculating someone's age as -1 years. If you
use unsigned and write the same code with the same bug you end up with
the age as 4294967295 years (assuming 32 bits as an example). Who
cares that one of those numbers happens to be >0? They are both as
wrong as the other. The code needs to be fixed whether age is signed
or unsigned, and once it is fixed, it will work whether age is signed
or unsigned.

--
GJD

[Gavin Deane]

Re: negative number evaluating greater than string.size()

Jorge Rivera <jorgeri@roches ter.rr.com> wrote in message news:<1NxZb.332 33$um1.16156@tw ister.nyroc.rr. com>...[color=blue][color=green]
> >
> > Suggest you read the recent thread 'time to get rid of unsigned?', started
> > on 17/02/04.
> >
> > john
> >
> >[/color]
>
> I read all the whining about unsigned, and still disagree....
>
> Regardless, what sense does it make to have a string with size < 0?[/color]

You missed the point. With a signed string size type, any code that
ends up with a size < 0 has a bug. If that same code had been written
with an unsigned string size type, it would still have a bug. The
garbage size value would now happen to be > 0, but so what? That
doesn't make the code any more correct. It is the same bug,
manifesting itself in a different way.

--
GJD
[color=blue]
> Furthermore, he should have been using
> void something(std:: string::size_ty pe)
> to start with.
>
> In my mind, this is just a problem of people not reading the standard
> documentation.
>
> The least programmers should do is see the header files to understand
> what types are being used, not just trust their instincts.[/color]

[Jorge Rivera]

Re: negative number evaluating greater than string.size()

>[color=blue]
> You missed the point. With a signed string size type, any code that
> ends up with a size < 0 has a bug. If that same code had been written
> with an unsigned string size type, it would still have a bug. The
> garbage size value would now happen to be > 0, but so what? That
> doesn't make the code any more correct. It is the same bug,
> manifesting itself in a different way.
>[/color]

The point is simple, read the documentation, read the correct behavior
of std::string, use it appropriately.

std::string::si ze_type std::string::si ze()

can not return a negative number. If anything, functions within
std::string will return std::string::np os, and I doubt there is any
situtation in which std::size() would return it.

Any other assumptions about values returned by string are just that,
assumptions. The behavior of the class is what it is, and we all should
just play by its rules, not whine weahter the implementation is signed
or unsigned.

JLR