Re: 64 bit C++ and OS defined types
* Goran:
standard library has size methods with unsigned result type
... and standard people are right and you are wrong ;-).
Name advantages and problems. You didn't do it, you just showed that
you gain nothing by using unsigned. That's neither advantage nor a
problem, and that was your only argument.
Here, some advantages of unsigned:
1. size is a __count__. Conceptually, it's a natural number. Same for
indexing. There's no element at position -1. Again, conceptually, it's
a natural number. The data type used (unsigned) reflects that. (IMHO,
this reason alone removes any need for a discussion).
It is a Very Bad Idea to choose a C++ unsigned type to indicate numerical range,
because it doesn't enforce it. In Pascal, yes, there is a benefit; in Ada, yes,
there is a benefit; in C++, no, there is no benefit. On the contrary, in C++, by
doing that, you get all the problems and no benefits, hence it's plain stupid.
And I write that in spite of having mindlessly done the stupid thing for many
years (coming from Pascal/Modula-2, and seeing some experts doing the same in
C++), and having argued vociferously for it also in this group.
But it's never to late to learn, and when you start thinking about why the heck
you need an additional /hint/ that a size is non-negative, isn't "size" hint
enough, how dumb can a programmer be, really?, you realize that there's
something really fishy. Then thinking about actual benefits you find none, only
hand-waiving. Then thinking about problems and you find an abundance.
2. in practice, an underflow with unsigned on raw arrays and some
(past?) implementations of STL leads to an earlier crash than going in
with e.g. -1.
This is pretty unclear, but unsigned opens the door for more bugs, so this
argument about probability of detecting those bugs is pretty lame. :)
The problems with unsigned types are well known.
Your compiler, if it's any good, will warn you about comparisions
unsigned/signed. Those warnings are serious. Where you have such type mismatch
(which results from unsigned) you often have a bug. For example, if size is
unsigned and n is negative signed of small absolute value (which is typical),
then 'size < n' will often yield true because n is promoted to unsigned.
Your compiler cannot, however, warn you about arithmetic problems.
There's a host of bug vectors in that, including the main example of loop
counting down (incorrectly expressed).
One main problem is that you have to add casts and/or unnaturally choose types
and/or unnaturally express loops to avoid warnings and/or bugs (like infinite
loops) where you just know that those values are all non-negative. There would
have been no such problems with signed size types. So there's a lot of work
added just to avoid the problems one wouldn't have with signed sizes.
And a natural solution to that is to define one's own signed Size type.
And then define some generic function like
template< typename T > Size size( T const& );
Along with generic 'begin' and 'end' (that also work for raw arrays), and so on.
Hip hurray, all that **** removed.
Oh well, OK, not all, not by far. For such solutions cannot easily be
retrofitted onto existing code. But I argue for adopting the more sane way of
doing things for new code, including maintainance of old. :-)
Cheers, & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!