One problem I've been wrestling with for a long time is how to use the
C++ integral data types, vis-a-vis their size. The C++ rules
guarantee that a char is at least 1 bytes, a short and int at least 2
bytes, and a long at least 4 bytes. The rules also define a size
precedence to the types. In Stroustrup's book, it says that all type
sizes are multiples of char, "so by definition the size of a char is
1." According to the rules, that means 1 unit which can be any number
of bytes.
Why should I trust the compiler to optimize the memory usage of the
types behind my back? As for portability, wouldn't fixed,
unambiguosly-sized types be much more portable? Doesn't the ambiguity
open the door for me on my system X with compiler Y to rely on its
Z-byte representation of int? And if system-dependent optimization is
desired, wouldn't it be easier to do with fixed-size types instead?
One of my gripes is that the terminology is unclear. New programmers
can be especially confused. For example, 'short' and 'long' are
relative adjectives, and they don't say how big or at least how big.
The other extreme are the names like __int8, __int16, and __int32 in
MSVC++. Wouldn't I be much less likely to use something called __int8
to count numbers over 255, than I would something called char? On the
other hand, these keywords fix the size of the type and allow no room
for the compiler to optimize.
If I could invent new types, I would name them something like:
uint8, uint16, uint24, uintN, ... (unsigned integer types)
sint8, sint16, sint24, sintN, ... (signed integer types)
where N is any multiple of 8 greater than 0 (i.e. arbitrary precision
types would be built-in.) I feel the signed/unsigned aspect is better
part of the keyword, and not separate and optional. The Mozilla
sources are instructive in that their cross-platform code implements
macros following a similar convention; but macros are like pollution.
I'd further have a new keyword like "allowopt", which when placed
after the type keyword grants access to the compiler to optimize the
memory allocation of the type. For example, when I write "uint16
allowopt myCounter;", then I would unambiously be declaring, "Give me
a 16-bit, unsigned, integer called myCounter whose size the compiler
may optimize."
In most compilers, the default setting would be to enable optimization
for all the declarations, and a pragma could turn it off. I have
suspicions about why things are the way they are, but I'd like to hear
the experts' opinions.
C++ integral data types, vis-a-vis their size. The C++ rules
guarantee that a char is at least 1 bytes, a short and int at least 2
bytes, and a long at least 4 bytes. The rules also define a size
precedence to the types. In Stroustrup's book, it says that all type
sizes are multiples of char, "so by definition the size of a char is
1." According to the rules, that means 1 unit which can be any number
of bytes.
Why should I trust the compiler to optimize the memory usage of the
types behind my back? As for portability, wouldn't fixed,
unambiguosly-sized types be much more portable? Doesn't the ambiguity
open the door for me on my system X with compiler Y to rely on its
Z-byte representation of int? And if system-dependent optimization is
desired, wouldn't it be easier to do with fixed-size types instead?
One of my gripes is that the terminology is unclear. New programmers
can be especially confused. For example, 'short' and 'long' are
relative adjectives, and they don't say how big or at least how big.
The other extreme are the names like __int8, __int16, and __int32 in
MSVC++. Wouldn't I be much less likely to use something called __int8
to count numbers over 255, than I would something called char? On the
other hand, these keywords fix the size of the type and allow no room
for the compiler to optimize.
If I could invent new types, I would name them something like:
uint8, uint16, uint24, uintN, ... (unsigned integer types)
sint8, sint16, sint24, sintN, ... (signed integer types)
where N is any multiple of 8 greater than 0 (i.e. arbitrary precision
types would be built-in.) I feel the signed/unsigned aspect is better
part of the keyword, and not separate and optional. The Mozilla
sources are instructive in that their cross-platform code implements
macros following a similar convention; but macros are like pollution.
I'd further have a new keyword like "allowopt", which when placed
after the type keyword grants access to the compiler to optimize the
memory allocation of the type. For example, when I write "uint16
allowopt myCounter;", then I would unambiously be declaring, "Give me
a 16-bit, unsigned, integer called myCounter whose size the compiler
may optimize."
In most compilers, the default setting would be to enable optimization
for all the declarations, and a pragma could turn it off. I have
suspicions about why things are the way they are, but I'd like to hear
the experts' opinions.
Comment