64 bit architectures and C/C++

[Thomas M. Breuel]

   You have just made a non-portable assumption, namely that there
   *is* an integral type which holds an octet and that there *is* an
   integral type which holds two octets, and so on.  If you want
   "at least 8 bits", then use {,{,un}signed} char, and if you want
   "at least 16 bits", then use {,unsigned} short.  The ANSI standard
   guarantees those.  There is no need to introduce your own private
   names for them.  If you want "exactly 8 bits" or "exactly 16 bits",
   you have no reason to expect that such types will exist.

   I am greatly disappointed that C++, having added so much to C, has not
   added something like int(Low,High) to the language, which would stand
   for the "most efficient" available integral type in which both Low and
   High were representable.  The ANSI C committee were right not to add
   such a construct to C, because their charter was to standardise, not
   innovate.

I think allowing the programmer to specify arbitrary precision
integers is equally bad, since it adds too much complexity to
the language and to compilers.

A good compromise would be to provide a set of precisions that can be
supported on current machines and extend the language standard
as newer, more powerful machines become available.

In essence, this is actually what the C standard does, if one
continues to use the current data types with roughly their current
meaning: "short" is close to, and at least 16 bits, and "long" is
close to, and at least 32 bit. The emphasis here is on "close to", and
this should probably be made explicit in the standard, since
programmers pragmatically do, and need to, rely on it to be able to
estimate what the space requirements of their programs will be.

When machines capable of handling larger integer data types become
available, new names for the new data types should be introduced.
Perhaps a more consistent naming scheme would be good: int8 (>= 8bit
integer), ..., int128 (>= 128 bit integer), etc.

					Thomas.