Are unsigned integers necessary?

[DaveB]

The Java designers didn't think there was any need to have unsigned
integers. Probably because they handle the errors well and don't leave as
much room for undefined behavior? Also, they have a 16-bit char for
Unicode. Is there anything on the table for the next C++ standard in
regards to improving the reliability of coding with integers or is the
current state of affairs something that has to be dealt with for
compatibility reasons? I'm not sure what all the issues are and whether
they can be corrected even.

 

[Ian Collins]

The Java designers didn't think there was any need to have unsigned
integers. Probably because they handle the errors well and don't leave as
much room for undefined behavior? Also, they have a 16-bit char for
Unicode. Is there anything on the table for the next C++ standard in
regards to improving the reliability of coding with integers or is the
current state of affairs something that has to be dealt with for
compatibility reasons? I'm not sure what all the issues are and whether
they can be corrected even.

Have you see the "How to elegantly get the enum code from its string
type" thread?

All there is to say on the subject (and more) has been said there.

To answer you subject, yes, they are.

 

[Bo Persson]

If you are shifting bits to the right, it makes a big difference
whether the type is signed or unsigned.

And Java "solves" that by adding an additional shift operator >>>.




Bo Persson

 

[Krice]

Is there anything on the table for the next C++ standard in
regards to improving the reliability of coding with integers

Unsigned is just a type among others. Nothing special about it.
The programmer is responsible for reliable code.

 

[James Kanze]

The Java designers didn't think there was any need to have
unsigned integers. Probably because they handle the errors
well and don't leave as much room for undefined behavior?

Or not. It's a lot harder to implement a good hash code under
Java, for example. And the interaction between the sign bit and
or'ing and and'ing isn't very intuitive. And of course, Java
doesn't allow access to raw memory (traditionally unsigned char
in C).

 

[Stuart Redmann]

The Java designers didn't think there was any need to have unsigned
integers. Probably because they handle the errors well and don't leave as
much room for undefined behavior?

How should error handling and unsigned integers be related to each
other? Do you mean that the usage of unsigned integers will increase
the number of programming errors?

I really can't see your point. As far as I can remember the Java
developers did not add unsigned integers to the Java language because
they didn't want to confuse programmers with unnecessary data types
(remember that Java was originally intended to be used to "spice up"
the internet, no for any kind of scientific computation).

Also, they have a 16-bit char for
Unicode. Is there anything on the table for the next C++ standard in
regards to improving the reliability of coding with integers or is the
current state of affairs something that has to be dealt with for
compatibility reasons? I'm not sure what all the issues are and whether
they can be corrected even.

The reliability of coding with integers? As far as I know there is
_no_ difference between an integer in Java and an integer in C: both
languages lack the support to check for overflow (in contrast to Ada,
for example). I guess that this state of affairs will continue.

Regards,
Stuart

 

[DaveB]

Have you see the "How to elegantly get the enum code from its string
type" thread?

No, but I'll check it out.

All there is to say on the subject (and more) has been said there.

To answer you subject, yes, they are.

Curt answers aren't very helpful. Perhaps you were just to busy to say
why.

 

[DaveB]

How should error handling and unsigned integers be related to each
other? Do you mean that the usage of unsigned integers will increase
the number of programming errors?

I really can't see your point. As far as I can remember the Java
developers did not add unsigned integers to the Java language because
they didn't want to confuse programmers with unnecessary data types
(remember that Java was originally intended to be used to "spice up"
the internet, no for any kind of scientific computation).

I can see the value in designing a clean language syntax without
unnecessary elements, but what was the tradeoff?

The reliability of coding with integers? As far as I know there is
_no_ difference between an integer in Java and an integer in C: both
languages lack the support to check for overflow (in contrast to Ada,
for example). I guess that this state of affairs will continue.

There has been a thread or more than one on which is better to use as a
default: signed or unsigned, but I didn't retain the resultant theory of
those thread. No need to restart those convos though, I'll search for the
info in the archives when I have time.

 

[Alf P. Steinbach]

* DaveB:

There has been a thread or more than one on which is better to use as a
default: signed or unsigned,

Which is better to use as default: contact lenses or military boots?

One relevant question is "for what".

but I didn't retain the resultant theory of
those thread. No need to restart those convos though, I'll search for the
info in the archives when I have time.

Any good introductory book will also discuss this.


Cheers & hth.,

- Alf

 

[DaveB]

* DaveB:

Which is better to use as default: contact lenses or military boots?

One relevant question is "for what".



Any good introductory book will also discuss this.

Not in any in-depth-enough way. For instance:

Compare/contrast C++ integer and character types with those of Java.
Address implementation issues and usage issues and consequences of the
set of types chosen. That is what I wanted to know and probably more.
Heck, why stop at Java? Throw in Ada also while we're at it.

So not as easy a task as you thought.

 

[Alf P. Steinbach]

* DaveB:

Not in any in-depth-enough way. For instance:

Compare/contrast C++ integer and character types with those of Java.
Address implementation issues and usage issues and consequences of the
set of types chosen. That is what I wanted to know and probably more.
Heck, why stop at Java? Throw in Ada also while we're at it.

Hm. I'm not going to write that piece. For one, my familiarity with Ada is
purely theoretical, from books. However, you don't need someone else to do all
these language comparisions for you. What you need is only the fundamentals, the
basic understanding, from which you can easily evaluate the selection of types
in any language you care about, including Cobol if you want.

So not as easy a task as you thought.

I'm very happy that the influx of new blood to the group continues unabated, but
educating you folks about the Glorious Advantages & Benefits of reasoned
discussion is frustrating (I think it has to do with modern education which
leaves that out, to get good marks one has to be an unquestioning memorization
robot, and even in the area of pure memorization one has to be careful to not
correct former US vice president Dan Quayle when he corrects you about spelling
"potato"). In the welcome message and FAQ it's just assumed that people /know/
about reasoning. But as a soundbite style shortish summary, just (1) abstain
from turning every issue personal, and (2) do not assume that telepathy works
even though Alan Turing did: you're in good company, but it's rubbish.

Anyway, that said, for a quick summary & explanation of C++ signed/unsigned
issues, with some concrete program examples, see my ~last post in the
aforementioned "How to elegantly get the enum code from its string type" thread;
in a threaded view it's nearly the last article article in that thread.


Cheers & hth.,

- Alf

 

[Ian Collins]

No, but I'll check it out.


Curt answers aren't very helpful. Perhaps you were just to busy to say
why.

The answer was to read that thread. All that can be said on the subject
was said there.

 

[DaveB]

* DaveB:

Hm. I'm not going to write that piece.

I didn't mean for you to take that like I was asking you to do it. That's
why I offset it into a separate paragraph.

For one, my familiarity with Ada is purely theoretical, from books.
However, you don't need someone else to do all these language
comparisions for you. What you need is only the fundamentals, the basic
understanding, from which you can easily evaluate the selection of
types in any language you care about, including Cobol if you want.

No I need much more info than the fundamentals, trust me. I've been doing
this for about 20 years now.

I'm very happy that the influx of new blood to the group continues
unabated, but educating you folks about the Glorious Advantages &
Benefits of reasoned discussion is frustrating (I think it has to do
with modern education which leaves that out, to get good marks one has
to be an unquestioning memorization robot, and even in the area of pure
memorization one has to be careful to not correct former US vice
president Dan Quayle when he corrects you about spelling "potato"). In
the welcome message and FAQ it's just assumed that people /know/ about
reasoning. But as a soundbite style shortish summary, just (1) abstain
from turning every issue personal, and (2) do not assume that telepathy
works even though Alan Turing did: you're in good company, but it's
rubbish.

It's much more frustrating for me than you. I'm a bit intuitive and can
grasp a lot of info without a lot of verbage. Quite different than the
majority of people in these technical groups where every last detail has
to be spelled out, and of course for some here, one has to do that
because they opportunistically grasp at any chance that they can to
attempt to indicate that you just got off the boat.

Anyway, that said, for a quick summary & explanation of C++
signed/unsigned issues, with some concrete program examples, see my
~last post in the aforementioned "How to elegantly get the enum code
from its string type" thread; in a threaded view it's nearly the last
article article in that thread.

I will, but I highly doubt it has the comprehensiveness I was actually
seeking with my lead-in post that I hoped would shed some big-picture
info rather than simple info found in any text. I'll let you know after I
read the thread in the next few days if the info there is what I
ultimately was seeking.

 

[DaveB]

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?

 

[DaveB]

"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 */
}

Whilst the following is incorrect:

std::vector<int> v;
...
for (int i = 0; i != v.size(); ++i)
{
/* do stuff with v */
}

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.

 

[DaveB]

Try implementing semi-numerical algorithms (e.g. unbounded precision
integer math) without unsigned types. You end up masking after every
operation, and if you forget once you get bugs that are hard to locate.

So that piece of info seems to point to the java designers making things
conceptually simpler for the newbie at the expense of the engineer-level
developer. Good info. Keep it coming.

 

[DaveB]

You seem to be rather blinkered.

Whatever that means. Restating what I said above though, for now that I
read it, it reads like I use lower warning levels and don't care about
higher levels. Well it's exactly the opposite, I never use any other
setting than the highest warning level, ever. I was looking for info such
as what undefined behaviors could crop up when using signed rather than
unsigned and vice-versa, but that discussion is probably what is
happening in that other thread that other guy mentioned.

 

[Öö Tiib]

I was looking for info such
as what undefined behaviors could crop up when using signed rather than
unsigned and vice-versa, but that discussion is probably what is
happening in that other thread that other guy mentioned.

Converting unsigned type to signed type that cannot represent the
value is implementation-defined. Rest of the behaviors when mixing
arithmetic with operands of different signedness and size are defined.

The problem is that the results are unexpected or non-obvious at first
glance. Like for example signed one bit member of class. It can be
either -1 or 0, but that is unexpected for most people who meet that
beast in code first time.

Similar thing happens when calling virtual function from a
constructors body. Very well defined what happens but neverthless it
is very unexpected and confusing to most.

 

[Alf P. Steinbach]

* Ian Collins:

Try allocating >2GB of memory on a 32 bit system without unsigned integers.

At the application level code that concerns only 1 case, namely a >2GB array of
bytes.

It seldom happens, and can be dealt with if it does happen.


Cheers,

- Alf

 

[Ian Collins]

* Ian Collins:

At the application level code that concerns only 1 case, namely a >2GB
array of bytes.

It seldom happens, and can be dealt with if it does happen.

Efficiently and transparently?