Re: Uninitialised Unsigned Integral == Okay
"Tom1s" wrote:
Hyman Rosen posted:
NULL@NULL.NULL wrote:
Now, here's the bit pattern for the doors I want open, and
the ones I want closed: 11110 0011 1001 1111 But... opps...
wait a minute... certain combinations are invalid!
No. You misunderstand. Any type aside from chars may have
extra bits in its object representation aside from those
that form its value representation. Unsigned short always
has at least sixteen bits in its value representation, and
all combinations of those bits are legal. But it may have
extra bits that are unaffected by numerical operations - you
would be able to get at them by using memcpy into unsigned
char arrays.
So if it is said that an unsigned integral type is 16-Bit, all
it means is that you have 16 "value representation" bits? The
integral type may in fact be comprised of 32 bits in memory
(hypothetically) ?
It depends on what you say. If you say that a type has 16 bits
in its value representation, yes. If you say that it has 16
bits in its object representation, it means something else.
Just saying that a type has 16 bits doesn't say anything.
(FWIW: I've seen a lot of Fortran implementations where integers
had 32 bits in their object representation, but only 16 in their
value representation.)
Looking at the following code:
/* Assuming CHAR_BIT == 8
Assuming a short is 16-Bit.
16 bits what? Object representation, or value representation.
*/
typedef unsigned char u8;
typedef unsigned short u16;
Does all of this imply that the following expression need not
be true:
sizeof( u16 ) == sizeof ( u8 )
I usually would imply that this expression is not true. It's
probably true on some signal processors, but not on any machine
I've ever worked on.
Okay, so I'm starting to acquiesce to the whole idea of
"16-Bit != 16 bits", but it leaves one question lingering on
my tongue:
Is it not woefully inefficient to have invalid bit
patterns? I'd expect as much from a dumbed-down language like
Java for instance, but not from C++.
If it's what the hardware does, then you really can't avoid,
now, can you? (It's also used to some degree by some debugging
tools -- Purify associates a certain number of bits with each
pointer, for example, and checks them on each access. And that
does slow things down -- enough that I've never heard of an
application being delivered with Purify linked in.)
--
James Kanze GABI Software
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]