time to get rid of unsigned?

[lilburne]

You've chosen an excellent example, in which a signed type is necessary
to make the code "work." However, this is just blurring the line
between the responsibility of the programmer and the responsibility of
the language.

Actually I don't think it is a language issue per se. Rather its a
design decision on what type gets returned from the standard container
libraries. In this case the descision was that underflow in calculations
concerning the size of containers, will not be dealt with by using the
most natural expression form. We really aren't Babylonian's that can't
conceive of negative values, we live in the 21st Century and are well
versed in such numbers from our tax returns, and bank statements.

 

[Rob Williscroft]

Gavin Deane wrote in

Not if you ever want to subtract one such value from another, for
example, and get a meaningful result, because 2 - 3, when the
variables holding 2 and 3 are unsigned, doesn't give -1.

In a way it does, that's what modulo arithmatic does:

unsigned f( unsigned a, unsigned b )
{
unsigned c = a - b;
}

Now we *know* that a == b + f(a, b), we don't get this property
with signed int.

IOW If the programmer understands that they're doing arithmatic
mod 2^n, then the result of 2U - 3U is just as meaningful as -1.

It also has the advantage that you don't have to worry about that
pesky sign .

Rob.

 

[David Harmon]

I believe you are assuming 32 bits per integer.
Let us assume 8 bits per integer.

int is required to be at least 16 bits.
But many people would be surprised to see it be less than 32.

If (x-y) is required to be non-negative, then the calculation of it is
preceded in your code with
assert (x >= y);

So where's the problem?

 

[Julie J.]

My point is that when a range is in the domain of positive

integral values, one should use an unsigned data type.

Shouldn't have anything to do with range or domain. If you are doing integer
math, use a signed type.

 

[Nick Hounsome]

lilburne <[email protected]> wrote in message

snip snip snippetty snip.

What we really need is a poll here to see the percentage who would like to
get rid of it (or just advocate not using it because
it can never be removed from the language now).
AND
a poll of java users to see how many wish they had it.

java is a more recent language and the designer didn't think it was worth
having.
Mind you he didn't do const either and I think he was wrong on that one.

 

[E. Mark Ping]

Offset for example.
There big amount of viruses that used this type of calculations for
stack trashing. Microsoft "programmers" used in many places int
instead of unsigned and the result is OS with many many holes for
viruses.

The problem wasn't unsigned vs. signed. It was not checking inputs.

 

[Julie J.]

Absolutely NO reason to get rid of it. If you don't want it, globally define:

#define unsigned

or to be more specific

#define unsigned signed

And now unsigned types are effectively removed from your code. No need to
change the language.

There are very valid reasons for unsigned, such as size and counts where
negative values are illogical.

 

[E. Mark Ping]

What we really need is a poll here to see the percentage who would like to
get rid of it (or just advocate not using it because
it can never be removed from the language now).
AND
a poll of java users to see how many wish they had it.

Totally useless. Such a poll without a measure of competence of the
person answering the question would likely be misleading.

 

[lilburne]

What we really need is a poll here to see the percentage who would like to
get rid of it (or just advocate not using it because
it can never be removed from the language now).

I don't think anyone is seriously advocating the removal of
unsigned from the language, because there are obviously
cases were its use is worthwhile. What is unclear is whether
the type should be prevelent in public interfaces, because
you are more likely to encounter underflow with unsigned
expressions than with signed expressions, and the extra bit
is rarely useful.

NOTE: none of the above implies that unsigned should never
be used in an interface, nor that there are no cases where
the extra bit isn't useful.

 

[Julie J.]

Doesn't have anything to do with interfaces. If the value being represented is
a count or size (or similar where the range is non-negative), it should be
unsigned; if it is a value to be used in arithmetic (or similar where the range
is positive and negative), it should be signed.

If you are doing arithmetic that requires at least nbits-1, you are using the
wrong type and should use the next larger size (exceptions exist, but are the
exception and not the norm).

I suspect that the main reasons that unsigned doesn't have more mass appeal is
because:

- programmer is lazy, and doesn't want to type 'unsigned int', when in their
mind, 'int' will do just fine (even though it isn't the appropriate type).

- programmer doesn't understand differences (or consequences) of
signed/unsigned types, so just uses int 'to be safe'.

- someone else used int (when it should have been unsigned int, see reasons
above), and the programmer doesn't want to deal with signed/unsigned mismatch
warnings so just uses int as well (again, wrong type).

This thread wouldn't exist if we were all using the types properly.

 

[Gavin Deane]

Hi!



The discussion seems to be concentrating on whether, as a
bogus result of a buggy calculation, -1 is better than 4G. To
me they're both just plain wrong,

Absolutely. As I have said previously, whether you use signed or
unsigned, if this happens, you have a bug somewhere. Either way, it's
the same bug.

which strongly hints that
some kind of a guard should be inserted before the potentially
buggy calculation:

SOME_int a,b,result;

if( a<b ) throw SillyArgs(a,b);
result = a-b;

Now, if you agree with me so far (and I¨'d like to hear why,
if not),

I do

then isn't unsigned just a plain simple extension of the
allowable range of results, more than doubling from 2G-1 to
4G-1 (in systems where int = 32-bit)? For most applications
this probably doesn't make a big difference, but the point is
that for some others it will!

Yes, that's all it is. And that's a special case. If you are using
unsigned in preference to signed because you know you will have values
above 2G-1, you are already into implementation specific details about
the range of the types. But special cases happen, which is why I never
said I wanted unsigned banned.

Finally, if 2-3 != 4G bothers you now, then won't 2 / 3 != 0
bother you next? There is a reason for why we don't use
Complex<double> for everything, though it apparently would
let us forget about number domain problems for good (but
only apparently).

It is not the numerical value I end up with that bothers me. 2 - 3 is
illustrative. The problem I have is that, in the world of arithmetic
that I have grown up with since before I ever saw a computer, the
result of subtracting a positive integer from another positive integer
is not, in general, positive.

Yes, I know how unsigned arithmetic works in C++. But I don't want to
bother with the extra workload of having to think about it, when there
is a signed type available that loses me nothing [*] and behaves the
same way as all integers have always behaved, since I first learnt
about them at school.

[*] outside of special cases like your example above.

 

[red floyd]

And how is the 2-3 pathological case any different from the (signed)
pathological case of (2^31)-1 + 1 = -(2^31)? You still have a
pathological case.

 

[Jorge Rivera]

Absolutely NO reason to get rid of it. If you don't want it, globally define:

#define unsigned

or to be more specific

#define unsigned signed

And now unsigned types are effectively removed from your code. No need to
change the language.

But you are chaging default behavior. Unexpected users reading the
standard would be fairly pissed to see that there is no way of declaring
unsigned types.

 

[Clark Cox]

Thomas Matthews wrote:

I propose we keep the unsigned types. Many embbeded applications use
all the bits of an integer type and don't consider them as signed.

The unsigned types as such wouldn't harm anybody, as long as the
implicit conversions to and from signed integers were removed.[/QUOTE]

So, you think that the following should be illegal?:

for(unsigned i = 0; i < 20; ++i)
{
;
}

 

[John Harrison]

So, you think that the following should be illegal?:

for(unsigned i = 0; i < 20; ++i)
{
;
}

for(unsigned i = 0U; i < 20U; ++i)

Not too hard (but a bit tedious).

john

 

[Nick Hounsome]

Doesn't have anything to do with interfaces. If the value being represented is
a count or size (or similar where the range is non-negative), it should be
unsigned; if it is a value to be used in arithmetic (or similar where the range
is positive and negative), it should be signed.

Just about every count and size is used in an arithmetic expression
somewhere so
by your own argument they should be signed.

Even if they are not now there is no gaurantee that they wont be in future -
in particular it
is an implementation decision and it is desirable to design for future
enhancements hence
you appear to be arguing against yourself.

 

[Claudio Puviani]

What we really need is a poll here to see the percentage who would like to
get rid of it (or just advocate not using it because
it can never be removed from the language now).

A popular vote is completely irrelevant. Both the standard committee and the
compiler manufacturers are interested in the opinions of those who use C++ (and
therefore understand why unsigned exists), not in the irrational ramblings of
every Tom, Dick, and Harry who misses a feature from BASIC, Pascal, Java, etc.
because they didn't bother to learn C++ to an adequate level of proficiency.

AND
a poll of java users to see how many wish they had it.

If you had the slightest clue how little the C++ community gives a da*n about
what the Java community wishes they had or didn't have.

java is a more recent language

Which only means it has no excuse for the abominations it unleashed on the poor
saps who migrated to it.

and the designer didn't think it was worth having.

The designer (of Java) didn't think it was worth having pointers either. Or
performance. Or templates. Or contiguous storage of an object's sub-elements.
Java's design is centered around the attempt to stop idiots from doing stupid
things. The goal of C++ is to allow intelligent people to do intelligent things.
Pick your language.

This topic has drifted way into the absurd.

Claudio Puviani

 

[Julie J.]

Just about every count and size is used in an arithmetic expression

somewhere so
by your own argument they should be signed.

Could you please provide some evidence to back up your claim. I don't feel
that your statement is true.

Even if they are not now there is no gaurantee that they wont be in future -
in particular it
is an implementation decision and it is desirable to design for future
enhancements hence
you appear to be arguing against yourself.

This makes no sense. My point is, and has been, use the proper type for the
situation. You can't design for infinite future possibilities, however you can
design for the task at hand w/ an eye to the future.

Picking at my statements isn't the point of my response. As I've mentioned,
use the proper type for the situation. unsigned is a valid and proper type for
numerous situations, and therefore should be used over its signed counterpart.

 

[Julie J.]

I was responding to the previous poster's request for a poll.

No need for a poll, if someone doesn't want unsigned in their code, they can
effectively remove it without changing the language. I don't know what effect

 

[Jeff Schwab]

unsigned f( unsigned a, unsigned b )
{
unsigned c = a - b;

return c;