Are unsigned integers necessary?

[Öö Tiib]

Efficiently and transparently?

char (* a)[50000] = new char[50000][50000];

 

[Ian Collins]

Efficiently and transparently?

char (* a)[50000] = new char[50000][50000];

That's neither transparent, nor elegant!

 

[Alf P. Steinbach]

* Ian Collins:

Efficiently and transparently?

Depends to some degree on what you mean. First note that there can only be 1
such array of bytes at any time (in any given process). So it's a special case,
used for some special purpose.

If we're talking about a convention of not mixing signed/unsigned, then it's no
big deal: you know about this special 1 array, and you have no need to obtain
its size in your own code. You just make sure to store an end-pointer at the
time when you allocate the array (at that point using unsigned size), and access
the array elements via pointers or pointer based local part indexing instead of
all-over-the-array numerical indexing. That's that.

That might sound like if you need to be extra careful with this array just
because of the adoption of a convention of not mixing signed/unsigned.

But you need to be extra careful anyway, since that array *is* a special case no
matter how it's handled.

For given p1 and p2 pointing to bytes of that array, evaluating p2-p1 is
potentially Undefined Behavior (via §5.7/5) since the result is of signed
ptrdiff_t type.

That is, that special array is a special handle-with-extreme-care case no matter
how you handle it, including if you use unsigned types for indexing and size; it
can be handled efficiently, but not transparently as if it was any other array.

Summing up, if the signed ptrdiff_t is sufficient for handling some array
without UB, then (master of tautologies demonstrates his mastery) ptrdiff_t is
sufficient for handling that array without UB, and otherwise it isn't.


Cheers & hth.,

- Alf

 

[Ian Collins]

* Ian Collins:

Depends to some degree on what you mean. First note that there can only
be 1 such array of bytes at any time (in any given process). So it's a
special case, used for some special purpose.

If we're talking about a convention of not mixing signed/unsigned, then
it's no big deal: you know about this special 1 array, and you have no
need to obtain its size in your own code. You just make sure to store an
end-pointer at the time when you allocate the array (at that point using
unsigned size), and access the array elements via pointers or pointer
based local part indexing instead of all-over-the-array numerical
indexing. That's that.

That might sound like if you need to be extra careful with this array
just because of the adoption of a convention of not mixing signed/unsigned.

But you need to be extra careful anyway, since that array *is* a special
case no matter how it's handled.

For given p1 and p2 pointing to bytes of that array, evaluating p2-p1 is
potentially Undefined Behavior (via §5.7/5) since the result is of
signed ptrdiff_t type.

That is, that special array is a special handle-with-extreme-care case
no matter how you handle it, including if you use unsigned types for
indexing and size; it can be handled efficiently, but not transparently
as if it was any other array.

Summing up, if the signed ptrdiff_t is sufficient for handling some
array without UB, then (master of tautologies demonstrates his mastery)
ptrdiff_t is sufficient for handling that array without UB, and
otherwise it isn't.

Alf, you should consider politics as a change of career!

Was that a yes or a no?

 

[Öö Tiib]

Alf, you should consider politics as a change of career!

Was that a yes or a no?

Possibly the correct answer is that it is implementation-defined.
Maximum size of one object is implementation defined. Suggested (with
non-binding to conformance suggestion) was at least 0x40000 bytes at
2003.

 

[Bo Persson]

N.B. said signed pointer arithmetic can only address the range that
ptrdiff_t provides. This is less of an issue on 64-bit platforms
which typically have much less memory than a 64-bit address might
imply.

Right, so we can argue that having a single array using more that half
the available virtual address space is an anomaly. Attempts to solve
the problem includes 1) using unsigned integers for indexing, or 2)
changing the size of the address space.

Here 2) is the proper solution, and 1) is a cure that is just as bad
as the disease.


Bo Persson

 

[Ian Collins]

Right, so we can argue that having a single array using more that half
the available virtual address space is an anomaly. Attempts to solve
the problem includes 1) using unsigned integers for indexing, or 2)
changing the size of the address space.

Here 2) is the proper solution, and 1) is a cure that is just as bad
as the disease.

But what if you don't or can't do 2? 1 should still be an option and
that requires unsigned integers.

 

[Rui Maciel]

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.

But it does happen and support for that feature already exists. So, why should anyone want to
take it away? What is there to be gained?


Rui Maciel

 

[DaveB]

Don't get me started. Java was designed for beginners.

So you opine, and maybe you know, but I don't know whether you know or
not, so I'll assume that you are just opining. I think it was an attempt
mostly to create a C++-like language devoid of C++ idiosynchracies, to
some extent. I think the "making it easy for newbies" was down the list
of requirements, but I AM just opining.

That was
especially evident in the early versions of the Java library, which
was designed in ways that beginners would love but experienced
programmers would find limiting.

Like ALL libraries, the first implementation is never the last, for
things have to evolve. Building a lot of complexity or features into the
first release is bound to be a bit on the "lame" side, by design.

I firmly believe that that was
because the library was designed by beginners, so it had many
beginners' mistakes. And certainly in some areas that hasn't
improved; take a look at the specification for
java.util.SimpleTimeZone -- it's far from simple, and should have
been split into several subclasses.

How is the library today though? Pretty comprehensive with hundreds of
classes right? Is it better designed now too? All the major things seem
to be there and that's more than anyone can say about C++: GUI, threads,
DB... Of course to compare the 2 languages, one has to only compare from
a mile-high perspective because C++ is a systems-level programming
language and Java is not.

 

[DaveB]

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

Or using 8-bit ASCII.

 

[Alf P. Steinbach]

* Rui Maciel:

But it does happen

Never happened to me; I wrote "seldom" just to be conservative.

and support for that feature already exists.

Sorry, no, full support for such an array does not exist in C++. You're
generally into UB land if you subtract pointers that point into that array.

So, why should anyone want to take it away?

The question doesn't seem to make sense. Who's taking what away from you?

What is there to be gained?

By what?

I'm not sure that I understand what you mean or indeed that you yourself
understand what you mean, but it feels vaguely like someone arguing that one
should generally prefer gas lamps to electrical lighting because there's a cabin
that few if anyone has actually used and that's already being demolished, where
the electricity would be slightly less cheap if it was ever used.

Regardless of whether one thought that the person understood "gas lamp" and
"electricity" one would suspect a person making such an argument to be trolling.


Cheers & hth.,

- Alf

 

[Bo Persson]

But what if you don't or can't do 2? 1 should still be an option
and that requires unsigned integers.

You have to do it anyway.

So, with unsigned ints I can allocate a 3GB byte array. What if I
needed a 5 GB array?

Hardly worth designing a programming language around. Some of us now
believe the C++ committee made a mistake in std::vector::size_type.
And I believe there are committee members that agree.



Bo Persson

 

[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?

Now this thread has played its self out, it might be interesting to
consider where the protagonist's views on the subject originated.

I started my programming career as a hardware engineer in a team where
we programmed all our own hardware. The company's software developers
were all "application types" who didn't understand hardware. In that
world of registers and buses, just about everything is a bag of bits, so
using unsigned types is the natural way of things. I still enjoy
embedded programming and writing drivers, so I guess I'm stuck in the
use unsigned types mindset.

I bet most of those who dislike signed types are in the "application
types who didn't understand hardware" category.

 

[Andrew Poelstra]

Now this thread has played its self out, it might be interesting to
consider where the protagonist's views on the subject originated.

I started my programming career as a hardware engineer in a team where
we programmed all our own hardware. The company's software developers
were all "application types" who didn't understand hardware. In that
world of registers and buses, just about everything is a bag of bits, so
using unsigned types is the natural way of things. I still enjoy
embedded programming and writing drivers, so I guess I'm stuck in the
use unsigned types mindset.

I bet most of those who dislike signed types are in the "application
types who didn't understand hardware" category.

I have this mentality as well when working with binary
network protocols, when signed integers must be encoded
in a specific way (big-endian two's complement, hardly
an esoteric encoding, but even so.). Everything is just
bits on a wire, and it's counter-intuitive to read bits
as negative numbers.

Right now I'm doing embedded development and the same
idea applies.

However, when I'm doing mathematical programming, and
I'm using C for some reason (either for speed or to do
numerical analysis with fewer abstractions to think
though) (otherwise Lisp or Python are far nicer to work
with), I use signed types for numbers, because in math,
numbers are signed.

So perhaps there are people who unilaterally fall into the
"application" or "hardware" categories, but I think that
most people switch freely depending on the problem domain.

 

[Bo Persson]

Now this thread has played its self out, it might be interesting to
consider where the protagonist's views on the subject originated.

I started my programming career as a hardware engineer in a team
where we programmed all our own hardware. The company's software
developers were all "application types" who didn't understand
hardware. In that world of registers and buses, just about
everything is a bag of bits, so using unsigned types is the natural
way of things. I still enjoy embedded programming and writing
drivers, so I guess I'm stuck in the use unsigned types mindset.

I bet most of those who dislike signed types are in the "application
types who didn't understand hardware" category.

Unsigned type are good on this level. The problem in the C family is
that the type is called 'unsigned int' and not 'word'.

Nobody would consider 'word' as good type for vector indexing.


Bo Persson

 

[Michael Tsang]

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?

The lack of unsigned integers in Java makes writing hash functions very
difficult so they are necessary.