«

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.

On 04/15/10 08:41 PM, DaveB wrote:
> 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.

--
Ian Collins

Juha Nieminen wrote:
> On 04/15/2010 11:41 AM, DaveB wrote:
>> 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.
>
> 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

On 15 huhti, 11:41, "DaveB" <DBu...@usenet.net> wrote:
> 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.

On 15 Apr, 09:41, "DaveB" <DBu...@usenet.net> wrote:
> 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).

--
James Kanze

On 15 Apr., 10:41, "DaveB" <DBu...@usenet.net> wrote:
> 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

"Ian Collins" <ian-> wrote in message
news:...
> On 04/15/10 08:41 PM, DaveB wrote:
>> 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?

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.

"Stuart Redmann" <> wrote in message
news:bd4dc891-09a5-432f-9119-...
> On 15 Apr., 10:41, "DaveB" <DBu...@usenet.net> wrote:
>> 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).

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

>
>> 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.

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.

* 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

"Alf P. Steinbach" <> wrote in message
news:hq8p1t$oa2$...
>* 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.
>

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.