On Oct 31, 9:26 pm, john <j...@no.spamwrote:
I want to verify my memory.
0 doesn't necessarily mean all-bits-zero in integrals,
Yes and no. The standard requires a "pure binary"
representation for integrals, which means that all value bits 0
must represent the value 0. On the other hand, the standard
allows representations which have both a positive and a negative
0, one of which will not have all bits 0. It also allows
"padding" bits, which may be anything.
So roughly speaking: memset'ing an integral type with 0's
guarantees a zero representation, but the fact memcmp with a lot
of 0 bytes returns non-0 doesn't mean that the value isn't zero.
As far as the standard is concerned, too, the above only holds
for integral types. All bits zero (or memset'ing the object to
0) doesn't guarantee a 0.0 value for floating point, nor a null
pointer for a pointer. (In practice, I've never heard of an
implementation where it didn't work for floating point---perhaps
a Unisys series A. There very definitly have been machines
where it didn't work for pointers, however.)
and 1 byte is not necessarily 8 bits (that's why we have
numeric_limits<unsigned char>::digits). Right?
Right. Standard English usage, that one. A byte has never been
necessarily 8 bits (and in fact, in the original usage at IBM,
was 6 bits). Of course, the C++ standard does use the word in a
somewhat different since, since it allows the size of a byte to
be the same as the size of a word, and requires it to be at
least 8 bits, and that the number of bytes in a word must be an
integer. (Common usage on the PDP-10 was 5 seven bit bytes in a
36 bit word. The byte size was programmable, however, and
presumably any C/C++ implementations used 4 nine bit bytes.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
