sizeof requirements for fundamental types

[Kyle Kolander]

I recently looked over the faq item relating to fundamental type sizes:
http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5
and was a bit surprised, as I had been taught more-or-less the same
thing, just not the minimum gaurantees for short and long.

"C++ guarantees a char is exactly one byte which is at least 8 bits,
short is at least 16 bits, int is at least 16 bits, and long is at least
32 bits."

I looked in Stroustrup's book, The C++ Programming Language, and sure
enough he explains it just as is quoted above (don't know how I passed
over that before - anyhow...). I went to look in my copy of the C++
Standard 1998-09-01 and could not locate this requirement. I've read in
other threads that a newer version was released... was this a change in
the new version or am I just looking in the wrong spot? I was looking
in section 3.9.1 Fundamental Types.

A second related question has to do with the newer version of the
standard. What is the format of this document? Is it just the changes
to the version I have, or is it a complete document representing the
current state of the C++ standard?

Thanks,
Kyle

 

[John Carson]

I recently looked over the faq item relating to fundamental type
sizes: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5
and was a bit surprised, as I had been taught more-or-less the same
thing, just not the minimum gaurantees for short and long.

"C++ guarantees a char is exactly one byte which is at least 8 bits,
short is at least 16 bits, int is at least 16 bits, and long is at
least 32 bits."

I looked in Stroustrup's book, The C++ Programming Language, and sure
enough he explains it just as is quoted above (don't know how I passed
over that before - anyhow...). I went to look in my copy of the C++
Standard 1998-09-01 and could not locate this requirement. I've read
in other threads that a newer version was released... was this a
change in the new version or am I just looking in the wrong spot? I
was looking in section 3.9.1 Fundamental Types.

You need to piece together different parts of the standard, draw appropriate
conclusions and so on. The same is true of the definition of a POD type and
some other things. This is one reason why it is generally easier to learn
from a textbook than from the Standard.

A second related question has to do with the newer version of the
standard. What is the format of this document? Is it just the
changes to the version I have, or is it a complete document
representing the current state of the C++ standard?

You can get the complete thing in a PDF file or an over-priced book here:

http://www.techstreet.com/cgi-bin/detail?product_id=1143945

You can get a more reasonably priced book version here:

http://www.amazon.com/exec/obidos/A...7/sr=2-1/ref=pd_bbs_b_2_1/002-8558617-1965648

 

[Kyle Kolander]

You need to piece together different parts of the standard, draw appropriate
conclusions and so on. The same is true of the definition of a POD type and
some other things. This is one reason why it is generally easier to learn
from a textbook than from the Standard.

OK. Well, I'm sure this question has been asked before, but I'll ask
anyhow... *sigh* Why are the minimum size guarantees for fundamental types
intentionally omitted from section 3.9.1 of the standard? If indeed these
guarantees can be inferred from other parts of the standard, and it is the
intent of the standards committee that these guarantees exist, then why are
they not listed in the most relevant section? I mean come on! I can't be
alone on this one... Is this an open issue for the next version of the
standard? I believe it should be. How does everyone feel about this? I
recall a recent thread from comp.std.c++ about making the standard more
intelligible... this seems to fall directly under that category.

I'm also curious from which sections of the standard can these minimum size
guarantees be inferred? It is not that I do not believe you, because I do
believe you; however, I would very much like to put together a "proof" of
how these requirements can be derived from the standard.

You can get the complete thing in a PDF file or an over-priced book here:

http://www.techstreet.com/cgi-bin/detail?product_id=1143945

You can get a more reasonably priced book version here:

http://www.amazon.com/exec/obidos/A...7/sr=2-1/ref=pd_bbs_b_2_1/002-8558617-1965648

Customer reviews point out a terrible binding for the book... has anyone
purchased this book? What did you think of it?

 

[John Carson]

OK. Well, I'm sure this question has been asked before, but I'll ask
anyhow... *sigh* Why are the minimum size guarantees for fundamental
types intentionally omitted from section 3.9.1 of the standard? If
indeed these guarantees can be inferred from other parts of the
standard, and it is the intent of the standards committee that these
guarantees exist, then why are they not listed in the most relevant
section? I mean come on! I can't be alone on this one... Is this an
open issue for the next version of the standard? I believe it should
be. How does everyone feel about this? I recall a recent thread
from comp.std.c++ about making the standard more intelligible... this
seems to fall directly under that category.

I'm also curious from which sections of the standard can these
minimum size guarantees be inferred? It is not that I do not believe
you, because I do believe you; however, I would very much like to put
together a "proof" of how these requirements can be derived from the
standard.

I suspect that the minimum size guarantees may be inherited from C. Annex C
(appropriately enough) of the C++ standard discusses things inherited from C
(as well as differences from C), and this includes various constants like
INT_MIN. I am not sure of this, but it seems the most likely explanation.

As for the readability of the standard, it is not really intended as a
learning tool. I agree that it could be more readily intelligble than it is,
but re-writing it would be a massive effort and the result would undoubtedly
be "buggy" at first, causing nightmares for the implementers of compilers
trying to comply with the standard. Rather like a large code base, there is
a great reluctance to re-write it from scratch and the resources to do it
just aren't there. The fact that it is the product of a committee (with a
changing and diverse membership) is another reason for its current
character.