fundamental types

[Kyle Kolander]

Sorry, I sent this to comp.std.c++ and meant to send it here as well...


Why are the minimum size guarantees for fundamental types intentionally
omitted from section 3.9.1 Fundamental types of the C++ 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've been sorting through my reference material to find exactly how these
minimum size requirements can be inferred from the C++ standard. Listed
below is what I've come up with... unfortunately, given the references
within the standard, I cannot deduce what Stroustrup says in the following
second quote.

Sroustrup says the following in The C++ Programming Language Third Edition
on page seventy-five in section 4.6 Sizes:
"1 = sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)"
"In addition, it is guaranteed that a char has at least 8 bits, a short at
least 16 bits, and a long at least 32 bits."

The C++ faq lite agrees with this:
http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5
"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."

Harbison and Steele, in C A Reference Manual Fourth Edition, in section
5.1.1 Signed Integer Types, say the following:
"The C language does not specify the range of integers that the integral
types will represent, except to say that type int may not be smaller than
short and long may not be smaller than int. Many implementations represent
characters in 8 bits, type short in 16 bits, and type long in 32 bits, with
type int using either 16 or 32 bits depending on the implementation. ISO C
requires implementations to use at least these widths."

From what I can see in the standard,
3.9.1.2: "There are four signed integer types: "signed char", "short int",
"int", and "long int." In this list, each type provides at least as much
storage as those preceding it in the list. Plain ints have the natural size
suggested by the architecture of the execution environment (39); the other
signed integer types are provided to meet special needs." Where (39) says,
"that is, large enough to contain any value in the range of INT_MIN and
INT_MAX, as defined in the header <climits>."

18.2.2.1 Header <climits>. This section lists a table of defined constants
for various min/max values for types; however, the values are omitted.

18.2.2.2 "The contents are the same as the Standard C library header
<limits.h>."

Annex D D.5.1 Standard C library headers lists a table of C Headers, which
includes <limits.h>.


Please, can someone help explain this by providing the relevant quotes from
the C++ standard? I originally created a thread for this issue in
comp.lang.c++ and received reply from John Carson suggesting that it may be
inherited from C. Harbison and Steele claim that these guarantees do exist
in the C standard. I do not have a copy of the C standard, so I cannot
check that. If this is the case, it is my belief that this information
should be explicitly stated in the C++ standard as well. I'm going to send
this to comp.lang.c++, too, so sorry for the duplicate thread.

I want to add that I've seen many times that people "refer to the standard"
as the authoritative reference on things related to C++. I'd like to be
able to do this, and have tried -- unsuccessfully in this case. For those
people that do often refer to the standard, hopefully you can help me with
how to find what I want from the standard. In this case, I believe I looked
in the relevant sections and followed up on cross-references within the
standard. Does it really have to be so difficult to find something that
could so easily be stated in the relevant section? If nothing else, insert
the quote from Stroustrup's book,
"In addition, it is guaranteed that a char has at least 8 bits, a short at
least 16 bits, and a long at least 32 bits."

Thanks,
Kyle

 

[Victor Bazarov]

Sorry, I sent this to comp.std.c++ and meant to send it here as well...


Why are the minimum size guarantees for fundamental types intentionally
omitted from section 3.9.1 Fundamental types of the C++ 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?

[...]

See the beginning of the Standard. The 1990 C Language Standard is
included as a normative part of 1998 C++ (and 2003 C++, I believe).
So, unless the C++ Standard restates something, the C norms are in
effect. If you need to know the limits of the fundamental types, see
the [now obsolete] C Standard.

V

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Why are the minimum size guarantees for fundamental types intentionally
omitted from section 3.9.1 Fundamental types of the C++ 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 don't unnderstand your point. Things that are not in the most relevant
section does not exists?

Does it really have to be so difficult to find something that
could so easily be stated in the relevant section?

I think is even convenient that the standard documents are hard to read.
Otherwise, people may be tempted to read it as a learning manual, and start
to think that the language is a bizarre collection of obscure things.
Stroustrup say something similar about many readers or the "Annotated
Reference Manual" in "The design and evolution of C++".

A standard document has other priorities than be easy to read. It tries to
be unambiguous and technically correct. Usually each paragraph must be
readed and approved for many people, that verifies it carefully. Then
adding a redundant paragraph is a hard work.

And finally, if you want to be able to authoritative quote the standard, and
the standard refers to the old C standard, obviusly you need a copy of the
C standard. You say that the C++ standard must quote the appropriate
paragraphs... well, you only need to convince the majority of the C++
standards commitee that is very important for the future of the language
that you can look as a C++ authority without a copy of the old C
standard... good luck

 

[Kyle Kolander]

Sorry, I sent this to comp.std.c++ and meant to send it here as well...


Why are the minimum size guarantees for fundamental types intentionally
omitted from section 3.9.1 Fundamental types of the C++ 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?

[...]

See the beginning of the Standard. The 1990 C Language Standard is
included as a normative part of 1998 C++ (and 2003 C++, I believe).
So, unless the C++ Standard restates something, the C norms are in
effect. If you need to know the limits of the fundamental types, see
the [now obsolete] C Standard.

V

Thanks Victor! I'll look into that tomorrow morning.

It would be nice, from my POV, to at least see a reference stating something
to the effect that some of these fundamental types have defined minimum
sizes in the C Standard. If someone, like myself, is not familiar with the C
Standard, why would you even look there when the C++ Standard made no
mention of it. Obviously, from your reply, this is the intent of the
standards committee. *shrug* They go so far as to restate the relative
ordering of the types, so why not one step further? Why should we have to
be familiar with more than one language standard just to program in one
language? It is for reasons such as this that hardly any C++ developers I
know will go to the Standard for their answers -- the one I do know of, a
professor who teaches C++ regularly, was not aware of this either. *sigh* I
suppose I am just ranting at this point...

 

[Kyle Kolander]

I don't unnderstand your point. Things that are not in the most relevant
section does not exists?

My point is that it does not appear ANYWHERE in the C++ Standard. Victor
pointed out that it is in the C Standard, which the C++ standard includes by
default unless otherwise noted.

I think is even convenient that the standard documents are hard to read.
Otherwise, people may be tempted to read it as a learning manual, and start
to think that the language is a bizarre collection of obscure things.
Stroustrup say something similar about many readers or the "Annotated
Reference Manual" in "The design and evolution of C++".

OK, I'm not looking for a conversational writing style in the Standard...
I just want to be able to find the answer in the actual Standard document...

A standard document has other priorities than be easy to read. It tries to
be unambiguous and technically correct. Usually each paragraph must be
readed and approved for many people, that verifies it carefully. Then
adding a redundant paragraph is a hard work.

I don't believe the minimum size guarantees of fundamental types is any more
redundant than the partial ordering of the sizes of fundamental types... I
have to believe both are stated in the C Standard. So why does only one of
the two appear in the C++ Standard?

And finally, if you want to be able to authoritative quote the standard, and
the standard refers to the old C standard, obviusly you need a copy of the
C standard. You say that the C++ standard must quote the appropriate
paragraphs...

If it must be that the C++ standard includes the C Standard as a reference,
then I am not even going so far as to require a quote. I would just like at
least a footnote, at a bare minimum, stating that minimum size requirements
exist and can be found in the C Standard.

well, you only need to convince the majority of the C++
standards commitee that is very important for the future of the language
that you can look as a C++ authority without a copy of the old C
standard... good luck

It would make more sense since C is not an exact subset of C++. Ideally,
just have one document that entirely and individually defines the language.
That seems reasonable.

Thanks for your reply.

Kyle

 

[Victor Bazarov]

[..]
It would be nice, from my POV, to at least see a reference stating something
to the effect that some of these fundamental types have defined minimum
sizes in the C Standard. If someone, like myself, is not familiar with the C
Standard, why would you even look there when the C++ Standard made no
mention of it.

You cannot use the Standard as if it were a Reference, and expect to find
all relevant information in _every_ section of it (even as footnotes). If
it were the intent, the Standard document wouldn't fit on a CD or maybe
even a DVD. It's like any other _statute_, as concise and compact as
possible with _every_ definition occurring only once, to minimize the
possibility to make a mistake (or hunt for all of them when time comes to
change something).

> Obviously, from your reply, this is the intent of the
standards committee. *shrug* They go so far as to restate the relative
ordering of the types, so why not one step further?

And when should they stop? See the problem yet?

> Why should we have to
be familiar with more than one language standard just to program in one
language?

Actually, to program in the language, you don't need to even be familiar
with the Standard. Read books, manuals, attend courses. The Standard is
not for the general programming public. But once you decide to open it,
don't complain that it's not what you expected.

> It is for reasons such as this that hardly any C++ developers I
know will go to the Standard for their answers -- the one I do know of, a
professor who teaches C++ regularly, was not aware of this either. *sigh* I
suppose I am just ranting at this point...

Yes, you are.

V

 

[Pete Becker]

I don't believe the minimum size guarantees of fundamental types is any more
redundant than the partial ordering of the sizes of fundamental types... I
have to believe both are stated in the C Standard. So why does only one of
the two appear in the C++ Standard?

Because somebody forgot to remove the other one.

 

[Jack Klein]

Sorry, I sent this to comp.std.c++ and meant to send it here as well...


Why are the minimum size guarantees for fundamental types intentionally
omitted from section 3.9.1 Fundamental types of the C++ 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?

Neither C nor C++ define any size at all for the fundamental types, or
any other types either, except that they are all greater than or equal
to one byte.

The C++ standard does refer to the C headers <limits.h> and <float.h>,
making them normative in C++.

<limits.h> contains macros that evaluate to the minimum and maximum
value that may be stored in each integer type. Actually, only the
maximum for the unsigned types, since the minimum is 0. The C
standard has a section where it defines the minimum magnitude an
implementation must define for these macros.

For example, INT_MIN must be less than or equal to -32767, and INT_MAX
must be greater than or equal to 32767. To represent the minimum
range (and 0) requires 65535 distinct values. Logically that means an
int must contain at least 16 bits, but it is not stated in that form,
only in terms of the range of values.

Even if the C standard specified the width of an int in bits, that
does not say anything at all about its width in bytes. There are C
and C++ compilers these days for some architectures, most notably
Digital Signal Processors, where a byte has 16 or 32 bits. So
sizeof(int) is 1 in these implementations.

The situation for the floating point types is even more complex, but
the values in <float.h> provide some help. While C and C++ assume and
require binary representation for integer types, they do not specify
anything at all about floating point types.

There are macros in <float.h> that specify things like the exponent
range and the number of decimal digits each floating point type can
represent accurately. If you assume a binary representation something
like IEEE 754, you could work out the minimum number of bits required
to provide what an implementation's <float.h> header defines.

But that still tells you nothing about their sizes in bytes. Both the
Analog Devices SHARC and the Texas Instruments 2812 represent floats
in IEEE 754 format, using 32 bits. But sizeof(float) is one on the
SHARC and two on the TI.

I've been sorting through my reference material to find exactly how these
minimum size requirements can be inferred from the C++ standard. Listed
below is what I've come up with... unfortunately, given the references
within the standard, I cannot deduce what Stroustrup says in the following
second quote.

Sroustrup says the following in The C++ Programming Language Third Edition
on page seventy-five in section 4.6 Sizes:
"1 = sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)"

Actually, this statement is neither guaranteed nor required by the C
standard, although it is by C++.

"In addition, it is guaranteed that a char has at least 8 bits, a short at
least 16 bits, and a long at least 32 bits."

The C++ faq lite agrees with this:
http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5
"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."

Harbison and Steele, in C A Reference Manual Fourth Edition, in section
5.1.1 Signed Integer Types, say the following:
"The C language does not specify the range of integers that the integral
types will represent, except to say that type int may not be smaller than
short and long may not be smaller than int. Many implementations represent
characters in 8 bits, type short in 16 bits, and type long in 32 bits, with
type int using either 16 or 32 bits depending on the implementation. ISO C
requires implementations to use at least these widths."

From what I can see in the standard,
3.9.1.2: "There are four signed integer types: "signed char", "short int",
"int", and "long int." In this list, each type provides at least as much
storage as those preceding it in the list. Plain ints have the natural size
suggested by the architecture of the execution environment (39); the other
signed integer types are provided to meet special needs." Where (39) says,
"that is, large enough to contain any value in the range of INT_MIN and
INT_MAX, as defined in the header <climits>."

18.2.2.1 Header <climits>. This section lists a table of defined constants
for various min/max values for types; however, the values are omitted.

18.2.2.2 "The contents are the same as the Standard C library header
<limits.h>."

Annex D D.5.1 Standard C library headers lists a table of C Headers, which
includes <limits.h>.


Please, can someone help explain this by providing the relevant quotes from
the C++ standard? I originally created a thread for this issue in
comp.lang.c++ and received reply from John Carson suggesting that it may be
inherited from C. Harbison and Steele claim that these guarantees do exist
in the C standard. I do not have a copy of the C standard, so I cannot
check that. If this is the case, it is my belief that this information
should be explicitly stated in the C++ standard as well. I'm going to send
this to comp.lang.c++, too, so sorry for the duplicate thread.

I want to add that I've seen many times that people "refer to the standard"
as the authoritative reference on things related to C++. I'd like to be
able to do this, and have tried -- unsuccessfully in this case. For those
people that do often refer to the standard, hopefully you can help me with
how to find what I want from the standard. In this case, I believe I looked
in the relevant sections and followed up on cross-references within the
standard. Does it really have to be so difficult to find something that
could so easily be stated in the relevant section? If nothing else, insert
the quote from Stroustrup's book,
"In addition, it is guaranteed that a char has at least 8 bits, a short at
least 16 bits, and a long at least 32 bits."

Thanks,
Kyle

As you quoted above, the C++ standard incorporates by reference
<limits.h> and <float.h> from the C standard (as of 1995), and
specifically states that they have exactly the same meaning and
requirements. In addition, C++ adds the restriction about the sizes,
which C does not, although it would be a very perverse implementation
indeed where sizeof(short) > sizeof(int), which C allows and C++ does
not.

This is one of the cases where it might have been better if the C++
standard had directly duplicated the contents of the C standard. You
would have to ask committee members on comp.std.c why they decided not
to.

The consequence is that right now you have the C++ standard citing as
normative large portions of a now obsolete C standard. Technically,
the C standard that it refers to is withdrawn, and no longer exists.
The current C standard contains all sorts of things that are not part
of standard C++.

Just a few:

<limits.h> includes LLONG_MAX, LLONG_MIN, and ULLONG_MAX macros for an
integer type that does not exist in C++ (yet).

Many of the C library function prototypes are now required to include
the 'restrict' type qualifier, a keyword and qualifier that do not
exist in C++.

I have never tried to pin it down, but I would say at least half of
the C headers referred to in the C++ standard would post a problem
today. C headers that conformed to the current C standard would
generate syntax errors and constraint violations if compiled on a
conforming standard C++ compiler.

 

[Kyle Kolander]

Thanks for your reply! It is exactly the answer I was looking for. Many
thanks!

As you quoted above, the C++ standard incorporates by reference
<limits.h> and <float.h> from the C standard (as of 1995), and
specifically states that they have exactly the same meaning and
requirements. In addition, C++ adds the restriction about the sizes,
which C does not, although it would be a very perverse implementation
indeed where sizeof(short) > sizeof(int), which C allows and C++ does
not.

Do you know if the C Standard committee plans to add this in the next draft?

This is one of the cases where it might have been better if the C++
standard had directly duplicated the contents of the C standard.

I agree.

You would have to ask committee members on comp.std.c why they decided not

to.


comp.std.c or comp.std.c++ ? I have never posted to either of those before,
although I just tried with my original post (to comp.std.c++) but it has not
appeared yet. Is there generally quite a delay, or are they just not
allowing my post -- it's moderated, right? Sorry for my ignorance on the
matter.

The consequence is that right now you have the C++ standard citing as
normative large portions of a now obsolete C standard. Technically,
the C standard that it refers to is withdrawn, and no longer exists.
The current C standard contains all sorts of things that are not part
of standard C++.

Right. So unless it is guaranteed that the two languages will evolve in
parallel, it seems like a bad idea, i.e. source of confusion, for one to
cite the other. From what I've read, Stroustrup would like to bring the two
together so that C would be a subset of C++. Maybe I interpreted that
incorrectly?

Thanks,
Kyle