signed/unsigned..?

in Large Scale c++ Design, John Lakos suggests that you should avoid the
"unsigned" keyword and use regular ints. Now I know that this book is
considered mostly outdated and I do use namespaces (which he also suggests
avoiding) and other things, but this particular topic has me puzzled.

The problem is that stl has a lot of size_t types that are unsigned and
since I run a no-warning policy, this forces me to do a lot of casting if
using pure int's. On the other hand, when you start to have unsigned
variables, I find that you risk getting errors that can be extremely subtle
and hard to track down.

Advertisements

"Søren Johansen" <nospam@please> wrote in message
news:3fd9a963$0$182$...
> Hi,
>
> in Large Scale c++ Design, John Lakos suggests that you should avoid the
> "unsigned" keyword and use regular ints. Now I know that this book is
> considered mostly outdated and I do use namespaces (which he also suggests
> avoiding) and other things, but this particular topic has me puzzled.
>
> The problem is that stl has a lot of size_t types that are unsigned and
> since I run a no-warning policy, this forces me to do a lot of casting if
> using pure int's. On the other hand, when you start to have unsigned
> variables, I find that you risk getting errors that can be extremely subtle
> and hard to track down.
>

I don't know in what context Lakos has made the statement.
But it's not correct to assume size_t is unsigned int or anything else.
Take example of std::string.
#include <string>
int main()
{
std::string Buffer("abc");
std::string::size_type loop = Buffer.length ();
}

If you take Buffer.length() to fit into an unsigned int, the result may/may not
be correct depending on whether
std::string::size_type is actually unsigned int or not. So to be safe always
use the size types provided by the class.

Hendrik Belitz wrote:
> Søren Johansen wrote:
>
>> Hi,
>>
>> in Large Scale c++ Design, John Lakos suggests that you should avoid the
>> "unsigned" keyword and use regular ints.
>
> I don't agree with this. Especially for range checking purposes the usage
> of unsigned values is preferable. Just look at the following example.

That's what I thought once too. But then it took me two days to find the
following bug in my program:

> I don't know in what context Lakos has made the statement.
> But it's not correct to assume size_t is unsigned int or anything else.
> Take example of std::string.
> #include <string>
> int main()
> {
> std::string Buffer("abc");
> std::string::size_type loop = Buffer.length ();
> }
>
> If you take Buffer.length() to fit into an unsigned int, the result
may/may not
> be correct depending on whether
> std::string::size_type is actually unsigned int or not. So to be safe
always
> use the size types provided by the class.

I realize this but there are some things that I dislike about it.
Consider this (made up) simple example:

Here, it seems to me that having to use the std::vector::size_type reveals
more implementation than I like in the interface. Furthermore, what if you
were to use the same index for two containers of different types?

Yes but if you only want to make sure i is positive, and i has been assigned
to some unsigned value, you would have to check for i < 2147483647..
Wouldn't you? My point is that it seems that unsigned values don't really
solve the problem that they appear to. Yes, an unsigned value can never be
negative but assigning a signed value to it or comparing with a signed value
produces weird results.
The argument about the one extra bit that is gained seems to me to only be
viable in very few, special cases. Your argument is better but on the other
hand it can produce errors that are hard to identify.

"Søren Johansen" <nospam@please> wrote in message
news:3fd9a963$0$182$...
> Hi,
>
> in Large Scale c++ Design, John Lakos suggests that you should avoid the
> "unsigned" keyword and use regular ints. Now I know that this book is
> considered mostly outdated and I do use namespaces (which he also suggests
> avoiding) and other things, but this particular topic has me puzzled.
>
> The problem is that stl has a lot of size_t types that are unsigned and
> since I run a no-warning policy, this forces me to do a lot of casting if
> using pure int's. On the other hand, when you start to have unsigned
> variables, I find that you risk getting errors that can be extremely
subtle
> and hard to track down.
>
> Any advice and experience appreciated.
>
> Søren
>
>

Sorry, I have no useful advice. I have the same problem and use casting to
int far more than I would like to.

Indeed, I missed this in my first response.
> There is no problem with that. But I know what you mean.
> I myself have been bitten lots of times by turning
>
> for( i = 0; i < nMax; ++i )
>
> around (because eg. I wanted to change the direction
> in which an array is traversed) to:
>
> for( i = nMax - 1; i >= 0; --i )
>
> if i is unsigned this will no longer work
>

It has become atomatic for me to do:

for ( i = nMax; i-- >= 0; )

Iterators (as a concept) help here as they force you to think
in terms of the fail condition, rather that the success condition,
"until" rather than "while" maybe.

Rob Williscroft wrote:
> Karl Heinz Buchegger wrote in news::
>
>>> for( i = nMax; i>0; --i ) {...
>>
>>
>
> Indeed, I missed this in my first response.
>
>> There is no problem with that. But I know what you mean.
>> I myself have been bitten lots of times by turning
>>
>> for( i = 0; i < nMax; ++i )
>>
>> around (because eg. I wanted to change the direction
>> in which an array is traversed) to:
>>
>> for( i = nMax - 1; i >= 0; --i )
>>
>> if i is unsigned this will no longer work
>>
>
> It has become atomatic for me to do:
>
> for ( i = nMax; i-- >= 0; )
>
>
> Iterators (as a concept) help here as they force you to think
> in terms of the fail condition, rather that the success condition,
> "until" rather than "while" maybe.
>
> for ( i = begin(); i != end(); ++i ) reverses to
> for ( i = end(); i-- != begin(); )
>
> Though it would really be:
>
> for( i = end(); i != begin(); )
> {
> --i;
> // ...
> }
>
> Just in case the iterator asserts on --begin().
>
> So we could write:
>
> for ( i = 0; i != nMax; ++i ) and
> for ( i = nMax; i-- != 0; )
>
> Iterators have a similar problem to unsigned, in that you can't
> meaningfully decrement to an element before the begining.

That's why there are reverse iterators:

for ( i = begin(); i != end(); ++i ) reverses to
for ( i = rbegin(); i != rend(); ++i)

Søren Johansen wrote:
>> I don't know in what context Lakos has made the statement.
>> But it's not correct to assume size_t is unsigned int or anything
>> else. Take example of std::string.
>> #include <string>
>> int main()
>> {
>> std::string Buffer("abc");
>> std::string::size_type loop = Buffer.length ();
>> }
>>
>> If you take Buffer.length() to fit into an unsigned int, the result
> may/may not
>> be correct depending on whether
>> std::string::size_type is actually unsigned int or not. So to be
>> safe
> always
>> use the size types provided by the class.
>
> I realize this but there are some things that I dislike about it.
> Consider this (made up) simple example:
>
> class Store
> {
> std::vector<int> _somevector;
> ..other stuff..
>
> public:
> std::vector::size_type GetElementCount() { return
> _somevector.size(); } void
> DoSomethingToElement(std::vector::size_type index);
> };
>
> Here, it seems to me that having to use the std::vector::size_type
> reveals more implementation than I like in the interface.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!