Re: Are unsigned integers necessary?
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:bNCdnR0xo_fHz1XWnZ2dnUVZ7qSdnZ2d@giganews.com...
"DaveB" <DBurns@usenet.net> wrote in message
news:jjYxn.58661$vC3.11369@newsfe04.iad...
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:ZLadnVpFLpup3VXWnZ2dnUVZ8mydnZ2d@giganews.com...
Yes.
That there is Java and that it does not have them indicates NO. The
question, then, becomes about what the tradeoffs are. Maybe in a VM
environment the elimination of unsigned integers is easier to accept?
"Yes" was the answer to your post's subject question within the context
of C++.
I was asking in general though. The body of the OP should have made that
quite clear, for it did bring up java, so the question was really for
those who have a scope of knowledge beyond just C++, and beyond just the
usage level even, for implementation issues are just as important to me.
C++ already has unsigned integral types which will not be removed from
the language. There exists much code which uses unsigned integral
types including libraries and the C++ standard library so avoiding the
use of unsigned integral types when writing new code is not really
possible.
I hate it when people regurgitate that. By now you would think that
everyone would assume that everyone knows about the C/C++ baggage issue
and it need not be continually re-emphasized.
The following is correct:
std::vector<int> v;
typedef std::vector<int>::size_type index;
...
for (index i = 0; i != v.size(); ++i)
{
/* do stuff with v[i] */
}
Whilst the following is incorrect:
std::vector<int> v;
...
for (int i = 0; i != v.size(); ++i)
{
/* do stuff with v[i] */
}
Use the right tool (type) for the job.
If you use the incorrect form you have an unnecessary signed/unsigned
conversion and although this may not actually cause any runtime
problems for this particular use-case you will at the very least get a
compiler warning which is a clue to its incorrectness.
Any/all things that a compiler will flag at the highest warning level is
really not the info that I was seeking.