Re: Unsigned types are DANGEROUS??
On Mar 16, 8:13 pm, Gerhard Fiedler <geli...@gmail.com> wrote:
MikeP wrote:
For me, one of the most important differences is that range overflow
doesn't exist in unsigned types; arithmetic on them is defined to be
modulo arithmetic. With signed types, range overflow is UB.
Therefore, a (standard-conformant) compiler may produce code to catch
range overflow with signed types but not with unsigned types. And some
actually do. IMO this helps create more robust applications.
I like that point of view, but you'll have to admit that the
argument would be a lot less vacuous if such implementations
actually existed. (I think one does, but it's certainly not
widely used.)
To me, this characteristic of unsigned types makes it pretty
obvious that they were designed for modulo arithmetic -- which
has its places and uses, but in most cases where unsigned types
are used is not what is intended. And most programmers simply
forget that signed and unsigned types are different in this
(IMO important) aspect.
The major characteristic of unsigned is that they have different
behavior than signed. In many ways. The real question is which
different behavior a reader will assume you meant to signal by
using unsigned. And the issue isn't obvious: I'm less radical
about it that Stroustrup, and I'll use unsigned rather than mix
the two when faced with an interface I can't change.
When James sounded as if it was a compromise to use unsigned, it's
probably because it was. In many architectures there is no signed type
that is able to enumerate the full address space with its positive
range, so an unsigned type has to be used where this is required. (Focus
on "has to be used", which already sounds like "can't do better, even if
I wanted to" :)
Let's not forget that when the decision was made, 16 bit machines
dominated (except for mainframes, and they didn't support C).
The choice was 1) to force such machines to limit the size of
objects even more, or use a larger type, which generally required
a function call for such basic operations as ++, 2) to leave the
signedness of size_t implementation defined, with all the
problems that entails for writing portable code, or 3) to require
size_t to be unsigned (and provide a separate signed type,
ptrdiff_t, for most of the everyday uses). Fundamentally, none
of the alternatives was considered acceptable, but one had to be
chosen.
--
James Kanze