fundamental types

Discussion in 'C++' started by Kyle Kolander, Jul 14, 2005.

  1. 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
     
    Kyle Kolander, Jul 14, 2005
    #1
    1. Advertising

  2. Kyle Kolander wrote:
    > 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
     
    Victor Bazarov, Jul 14, 2005
    #2
    1. Advertising

  3. Kyle Kolander wrote:

    > 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 ;)

    --
    Salu2
     
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Jul 14, 2005
    #3
  4. "Victor Bazarov" <> wrote in message
    news:DkABe.18601$01.us.to.verio.net...
    > Kyle Kolander wrote:
    > > 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, Jul 14, 2005
    #4
  5. "Julián Albo" <> wrote in message
    news:...
    > Kyle Kolander wrote:
    >
    > > 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?


    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.

    >
    > > 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++".


    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.

    >
    > --
    > Salu2


    Thanks for your reply.

    Kyle
     
    Kyle Kolander, Jul 14, 2005
    #5
  6. Kyle Kolander wrote:
    > [..]
    > 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
     
    Victor Bazarov, Jul 14, 2005
    #6
  7. Kyle Kolander

    Pete Becker Guest

    Kyle Kolander wrote:
    >
    > 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.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Jul 15, 2005
    #7
  8. Kyle Kolander

    Jack Klein Guest

    On Thu, 14 Jul 2005 15:34:02 -0500, "Kyle Kolander"
    <> wrote in comp.lang.c++:

    > 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.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Jul 15, 2005
    #8
  9. 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

    >
    > --
    > Jack Klein
    > Home: http://JK-Technology.Com
    > FAQs for
    > comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    > comp.lang.c++ http://www.parashift.com/c -faq-lite/
    > alt.comp.lang.learn.c-c++
    > http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Kyle Kolander, Jul 15, 2005
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alf P. Steinbach
    Replies:
    30
    Views:
    864
    Dave Thompson
    Feb 14, 2005
  2. Alf P. Steinbach

    FAQ issue: Guaranteed value ranges of fundamental types?

    Alf P. Steinbach, Feb 5, 2005, in forum: C Programming
    Replies:
    30
    Views:
    712
    Dave Thompson
    Feb 14, 2005
  3. Kyle Kolander
    Replies:
    3
    Views:
    282
    John Carson
    Jul 14, 2005
  4. Francesco S. Carta
    Replies:
    8
    Views:
    312
    Francesco S. Carta
    Aug 29, 2010
  5. Pavel
    Replies:
    13
    Views:
    1,090
    Pavel
    Jul 5, 2011
Loading...

Share This Page