integral types

Discussion in 'C++' started by SasQ, Mar 24, 2007.

  1. SasQ

    SasQ Guest

    Hello.

    I'm wondering about something...
    Is C++ designed for 32-bit-and-more machines only?
    I've deduced it from the fact that a 'long int' type has to be
    at least 32-bit. Am I right or not? :|
    Is it possible to use C++ for some embedded platforms using
    16-bit or 8-bit integral arithmetics? If yes, how can it be done?
    Would 32-bit integers have to be emulated by implementation?
    Or maybe by dropping out the 'long int' type? [but is it still
    standard-complaint then?]

    --
    SasQ
    SasQ, Mar 24, 2007
    #1
    1. Advertising

  2. * SasQ:
    >
    > I'm wondering about something...
    > Is C++ designed for 32-bit-and-more machines only?


    No.


    > I've deduced it from the fact that a 'long int' type has to be
    > at least 32-bit. Am I right or not? :|


    'long int' has to be at least 32 bits.


    > Is it possible to use C++ for some embedded platforms using
    > 16-bit or 8-bit integral arithmetics?


    Yes.


    > If yes, how can it be done?


    Using a compiler for that platform, or perhaps a cross-compiler.


    > Would 32-bit integers have to be emulated by implementation?


    Yes.


    > Or maybe by dropping out the 'long int' type? [but is it still
    > standard-complaint then?]


    No, it wouldn't be standard-compliant by dropping 'long int', but the
    C++ standard differentiates between "hosted" and "free-standing"
    implementations, the latter being meant primarily for embedded work,
    allowed to drop (not offer) most of the standard library.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Mar 25, 2007
    #2
    1. Advertising

  3. SasQ

    Kai-Uwe Bux Guest

    SasQ wrote:

    > Hello.
    >
    > I'm wondering about something...
    > Is C++ designed for 32-bit-and-more machines only?


    No. C++ is designed for use on parameterized nondeterministic abstract
    machines only (see [1.9/1]). That there are C++ compilers for real machines
    is a quite astonishing miracle regardless of their word length.


    > I've deduced it from the fact that a 'long int' type has to be
    > at least 32-bit. Am I right or not? :|


    You are right in that long int has at least 32 bits. But I don't see how
    this implies anything about what C++ is designed for.


    > Is it possible to use C++ for some embedded platforms using
    > 16-bit or 8-bit integral arithmetics?


    Is that a question about the availability of C++ compilers for those
    platforms? If so, I suggest you investigate the particular platform you are
    interested in.


    > If yes, how can it be done? Would 32-bit integers have to be emulated by
    > implementation?


    Yes, that would be the way to go.


    > Or maybe by dropping out the 'long int' type? [but is it still
    > standard-complaint then?]


    That would not be standard compliant.


    Now, if you find that the compiler generated code to deal with 32 bit
    integer types is too bulky or slow and if you were willing to sacrifice the
    long integral types anyway, then you should find it acceptable to just not
    use the long integral types.


    Best

    Kai-Uwe Bux
    Kai-Uwe Bux, Mar 25, 2007
    #3
  4. * Kai-Uwe Bux:
    > SasQ wrote:
    >
    >> Hello.
    >>
    >> I'm wondering about something...
    >> Is C++ designed for 32-bit-and-more machines only?

    >
    > No. C++ is designed for use on parameterized nondeterministic abstract
    > machines only (see [1.9/1]). That there are C++ compilers for real machines
    > is a quite astonishing miracle regardless of their word length.


    That would be astonishing if C++ was defined in terms of the abstract
    machine -- because then seemingly the definition of the abstract
    machine itself would be nowhere to be found (searching the standard for
    "Vienna" or something like that would not yield any results, I think).

    Happily it's not the case that C++ is defined in terms of an abstract
    machine.

    The C++ standard defines the effects of execution of a C++ program /as/
    an abstract machine, i.e., the abstract machine is the effect of a C++
    program as per the rules for C++ programs. Sort of the other way from
    being defined in terms of. Which in particular means that statements in
    the standard about the effect of any construct should not be interpreted
    as the effect within some abstract machine (which would yield an
    infinitely recursive and impotent definition); instead it is directly
    the effect of the construct, and that /is/ the abstract machine.

    And the effects of various C++ constructs (and thereby, of the abstract
    machine, which is sum total of such effects) have been very carefully
    crafted to correspond to and be efficient on actual machines.

    C++, and C, are practical engineers' languages.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Mar 25, 2007
    #4
  5. SasQ

    Kai-Uwe Bux Guest

    Alf P. Steinbach wrote:

    > * Kai-Uwe Bux:
    >> SasQ wrote:
    >>
    >>> Hello.
    >>>
    >>> I'm wondering about something...
    >>> Is C++ designed for 32-bit-and-more machines only?

    >>
    >> No. C++ is designed for use on parameterized nondeterministic abstract
    >> machines only (see [1.9/1]). That there are C++ compilers for real
    >> machines is a quite astonishing miracle regardless of their word length.

    >
    > That would be astonishing if C++ was defined in terms of the abstract
    > machine -- because then seemingly the definition of the abstract
    > machine itself would be nowhere to be found (searching the standard for
    > "Vienna" or something like that would not yield any results, I think).
    >
    > Happily it's not the case that C++ is defined in terms of an abstract
    > machine.
    >
    > The C++ standard defines the effects of execution of a C++ program /as/
    > an abstract machine, i.e., the abstract machine is the effect of a C++
    > program as per the rules for C++ programs. Sort of the other way from
    > being defined in terms of. Which in particular means that statements in
    > the standard about the effect of any construct should not be interpreted
    > as the effect within some abstract machine (which would yield an
    > infinitely recursive and impotent definition); instead it is directly
    > the effect of the construct, and that /is/ the abstract machine.
    >
    > And the effects of various C++ constructs (and thereby, of the abstract
    > machine, which is sum total of such effects) have been very carefully
    > crafted to correspond to and be efficient on actual machines.
    >
    > C++, and C, are practical engineers' languages.


    My bad. The remark was meant as a joke, but I forgot to end the sentence
    with appropriate smiley punctuation.


    Best

    Kai-Uwe Bux
    Kai-Uwe Bux, Mar 25, 2007
    #5
  6. SasQ

    SasQ Guest

    Dnia Sat, 24 Mar 2007 21:18:29 -0400, Kai-Uwe Bux napisa³(a):

    >> I've deduced it from the fact that a 'long int' type
    >> has to be at least 32-bit. Am I right or not? :|

    >
    > You are right in that long int has at least 32 bits.
    > But I don't see how this implies anything about what
    > C++ is designed for.


    Because I don't know how to apply this rule of Standard
    to 8-bit or 16-bit machines.

    >> Is it possible to use C++ for some embedded platforms
    >> using 16-bit or 8-bit integral arithmetics?

    >
    > Is that a question about the availability of C++ compilers
    > for those platforms?


    No, it's the question about possibility to implement
    Standard rules for those platforms which don't have
    32-bit registers to stuff 'long int' into them.

    >> If yes, how can it be done? Would 32-bit integers have
    >> to be emulated by implementation?

    >
    > Yes, that would be the way to go.


    Huh.. OK... And are there any other ways?

    >> Or maybe by dropping out the 'long int' type?
    >> [but is it still standard-complaint then?]

    >
    > That would not be standard compliant.


    OK, one down... ;J

    --
    SasQ
    SasQ, Mar 28, 2007
    #6
  7. SasQ

    SasQ Guest

    Dnia Sun, 25 Mar 2007 03:07:46 +0200, Alf P. Steinbach napisa³(a):

    >> I've deduced it from the fact that a 'long int' type
    >> has to be at least 32-bit. Am I right or not? :|

    >
    > 'long int' has to be at least 32 bits.


    OK, thanks for assuring me for this rule of Standard.
    But I still don't know how could it be possible to apply
    that rule for platforms which are less than 32-bit and
    don't have 32-bit registers to fit 'long int'.

    >> Is it possible to use C++ for some embedded platforms
    >> using 16-bit or 8-bit integral arithmetics?

    >
    > Yes.


    Good :) How? :>

    >> If yes, how can it be done?

    >
    > Using a compiler for that platform, or perhaps
    > a cross-compiler.


    It's a circumlocutive answer ;P
    I'm rather interested in how to make that sizeof(long int)
    would give 4 on a 8-bit or 16-bit platform.
    The particular compiler would be a good example, but I can't
    find any standard-complaint 8-bit nor 16-bit compiler.

    >> Would 32-bit integers have to be emulated by implementation?

    >
    > Yes.


    Good to know. It's always one step further than nothing... :J

    >> Or maybe by dropping out the 'long int' type? [but is it still
    >> standard-complaint then?]

    >
    > No, it wouldn't be standard-compliant by dropping 'long int',
    > but the C++ standard differentiates between "hosted" and
    > "free-standing" implementations, the latter being meant
    > primarily for embedded work, allowed to drop (not offer)
    > most of the standard library.


    Yes, I know. I've seen that kind of stuff in a chapter about
    the main() function requirements [some people even have told me
    that Windows is an embedded/freestanding environment because of
    using nonstandard WinMain() function ;)].
    But I don't see anything about that in the chapter about
    built-in types. And not every 16-bit machine is "embedded" ;J

    --
    SasQ
    SasQ, Mar 28, 2007
    #7
  8. SasQ

    red floyd Guest

    SasQ wrote:
    > Dnia Sun, 25 Mar 2007 03:07:46 +0200, Alf P. Steinbach napisa³(a):
    >
    >>> I've deduced it from the fact that a 'long int' type
    >>> has to be at least 32-bit. Am I right or not? :|

    >> 'long int' has to be at least 32 bits.

    >
    > OK, thanks for assuring me for this rule of Standard.
    > But I still don't know how could it be possible to apply
    > that rule for platforms which are less than 32-bit and
    > don't have 32-bit registers to fit 'long int'.
    >

    Software emulation. Same way that C compilers for 8 bit machines
    emulated 32-bits (Ah, the good old Z-80!).
    red floyd, Mar 28, 2007
    #8
  9. SasQ wrote:

    >> You are right in that long int has at least 32 bits.
    >> But I don't see how this implies anything about what
    >> C++ is designed for.

    >
    > Because I don't know how to apply this rule of Standard
    > to 8-bit or 16-bit machines.


    The way to apply it is very simple. Just say: "In 8 or 16 bit machines a
    long int has at least 32 bits".

    > No, it's the question about possibility to implement
    > Standard rules for those platforms which don't have
    > 32-bit registers to stuff 'long int' into them.


    The same way the floating point format rules are implemented in machines
    that don't have floating point in the cpu or in a coprocessor. By designing
    rules and writing code.

    --
    Salu2
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Mar 28, 2007
    #9
  10. SasQ

    SasQ Guest

    Dnia Sun, 25 Mar 2007 01:57:59 +0100, SasQ napisa³(a):

    Thanks for everyone for their explanations.
    It has cleared me a couple of things.
    Now I'll try to sumarize it:

    Machine word: sizeof(long int):
    8-bit 4 Emulated as four 8-bit registers.
    16-bit 4 Emulated as two 16-bit registers.
    32-bit 4 Doesn't have to be emulated.
    64-bit 4 or 8? Doesn't have to be emulated.

    Now I have doubts only on 64-bit machines, where 'long int'
    may be that 'at least 32 bits', but it can be more also :p
    So if it can, sould it or not?

    Next, we have 'short int', which the Standard requires to be
    at least 16 bits. So, let's look:

    Machine word: sizeof(short int):
    8-bit 2 Emulated as two 8-bit registers
    16-bit 2 Doesn't have to be emulated.
    32-bit 2 Doesn't have to be emulated.
    64-bit 2 Doesn't have to be emulated.

    Here, I have some doubts on 64-bit platform. On 32-bit
    'short' is mostly 16-bit and no more, because it should be
    able to be shorter than plain 'int'. On 64-bit platforms
    it could be more, if plain 'int' were 64-bit. But I don't
    know how it is there, and I've seen only one particular
    case, where plain 'int' has still 32 bits, so the 'short
    int' has to be 16-bit.

    And now we come to plain 'int' type :p
    The Standard requires it to be at least as much as 'short int',
    and defines it as the type most convenient for integer arithmetics
    on the particular platform. So, if we apply the same rules as
    for 'long int' [with the emulation], we would get:

    Machine word: sizeof(int):
    8-bit 2?? Emulated as two 8-bit registers??
    16-bit 2 Doesn't have to be emulated.
    32-bit 4 Doesn't have to be emulated.
    64-bit 4 or 8? Doesn't have to be emulated.

    I don't think emulating 'int' as two 8-bit registers to be
    the most convenient for the 8-bit platform to compute on
    integers :p Even if 16-bit platforms could emulate C++
    Standard rules and feel good with it, for 8-bit machines
    there is something wrong, I think. Something, that was
    missed by the creators of Standard, or [more probably :p]
    by me :/ So what is the thing I am missing here?

    I think I know the theory [C++ Standard] but I don't know
    how to apply it in practice.

    --
    SasQ
    SasQ, Mar 29, 2007
    #10
  11. SasQ

    James Kanze Guest

    On Mar 29, 2:51 am, SasQ <> wrote:
    > Dnia Sun, 25 Mar 2007 01:57:59 +0100, SasQ napisa³(a):


    > Thanks for everyone for their explanations. It has cleared me
    > a couple of things. Now I'll try to sumarize it:


    > Machine word: sizeof(long int):
    > 8-bit 4 Emulated as four 8-bit registers.
    > 16-bit 4 Emulated as two 16-bit registers.
    > 32-bit 4 Doesn't have to be emulated.
    > 64-bit 4 or 8? Doesn't have to be emulated.


    You're still limiting yourself too much. C++ has nothing to say
    about the size of a machine word. All it guarantees is that
    char has at least 8 bits (but there have been implementations
    with 9, 10 and 32 bit chars, at least), that int is at least 16
    bits (I've seen 16, 32, 36 and 48---and 24 wouldn't surprise me
    for some machines I've heard of), that long is at least 32 bits,
    and the next standard will also require a long long of at least
    64 bits.

    In addition, you are guaranteed that the size of any type is a
    positive integral value, and that:

    sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

    Note that if char is 32 bits, all of the integral types can have
    a size of 1.

    > Now I have doubts only on 64-bit machines, where 'long int'
    > may be that 'at least 32 bits', but it can be more also :p
    > So if it can, sould it or not?


    All of the 64 bit machines I use have a 64 bit long. It seems
    the most natural.

    > Next, we have 'short int', which the Standard requires to be
    > at least 16 bits. So, let's look:


    > Machine word: sizeof(short int):
    > 8-bit 2 Emulated as two 8-bit registers
    > 16-bit 2 Doesn't have to be emulated.
    > 32-bit 2 Doesn't have to be emulated.
    > 64-bit 2 Doesn't have to be emulated.


    > Here, I have some doubts on 64-bit platform. On 32-bit
    > 'short' is mostly 16-bit and no more, because it should be
    > able to be shorter than plain 'int'.


    That's not required. On word addressed machines (e.g. Unisys
    2200), it's probably the same as int. In fact, on a Unisys
    2200, I would expect short, int and long all to have 36 bits.

    > On 64-bit platforms
    > it could be more, if plain 'int' were 64-bit. But I don't
    > know how it is there, and I've seen only one particular
    > case, where plain 'int' has still 32 bits, so the 'short
    > int' has to be 16-bit.


    There's no "has to" about it. In practice, on a byte addressed
    64 bit machine, the vendor will probably want to offer access to
    all natively supported lengths. Since there are four, and there
    are only four integral types, there is only one solution.

    > And now we come to plain 'int' type :p
    > The Standard requires it to be at least as much as 'short int',
    > and defines it as the type most convenient for integer arithmetics
    > on the particular platform. So, if we apply the same rules as
    > for 'long int' [with the emulation], we would get:


    > Machine word: sizeof(int):
    > 8-bit 2?? Emulated as two 8-bit registers??
    > 16-bit 2 Doesn't have to be emulated.
    > 32-bit 4 Doesn't have to be emulated.
    > 64-bit 4 or 8? Doesn't have to be emulated.


    > I don't think emulating 'int' as two 8-bit registers to be
    > the most convenient for the 8-bit platform to compute on
    > integers :p


    It's more convenient that using even more bytes, and it is the
    least the standard allows.

    > Even if 16-bit platforms could emulate C++
    > Standard rules and feel good with it, for 8-bit machines
    > there is something wrong, I think. Something, that was
    > missed by the creators of Standard, or [more probably :p]
    > by me :/ So what is the thing I am missing here?


    That people wanted C to be useful, and so defined a generally
    useful set of rules for the period. (One could easily argue
    today that an int should be required to be at least 32 bits.)
    C++ just took over these rules.

    > I think I know the theory [C++ Standard] but I don't know
    > how to apply it in practice.


    You apply it in practice by first deciding what your goals are.
    If you're code targets desktop computers or larger, for example,
    it's perfectly reasonable to assume that an int is at least 32
    bits. If your code makes extensive use of the Windows API, for
    its GUI, you might as well assume that int is 32 bits, and 2's
    complement to boot. If you think that your code might have to
    run on embedded systems, or on mainframes, or legacy systems,
    then you'll have to be a lot more careful. Still, for most
    code, all you have to worry about is the maximum and minimum
    values you need to handle.

    --
    James Kanze (GABI Software) email:
    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
    James Kanze, Mar 29, 2007
    #11
  12. SasQ

    SasQ Guest

    Dnia Thu, 29 Mar 2007 02:44:27 -0700, James Kanze napisa³(a):

    > C++ has nothing to say about the size of a machine word.
    > All it guarantees is that char has at least 8 bits
    > (but there have been implementations with 9, 10 and 32 bit
    > chars, at least), that int is at least 16 bits
    > (I've seen 16, 32, 36 and 48---and 24 wouldn't surprise me
    > for some machines I've heard of), that long is at least 32
    > bits, and the next standard will also require a long long of
    > at least 64 bits.


    Is it sure for now?
    Would there be 'long long long int' in a future then?

    And where do you know that from? I had problems with obtaining
    a copy of C++ Standard document [it isn't available for free in
    the Internet in a way W3C standards do, so I had to borrow a copy
    from a friend], and the more for obtaining any information about
    the new C++0x Standard plans.

    > In addition, you are guaranteed that the size of any type is a
    > positive integral value


    Good to know that it wouldn't be negative or a fraction :p :)
    I haven't seen any negative size in my life yet :)))

    > and that:
    >
    > sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)


    Yeah, that's what I've known before.

    > Note that if char is 32 bits, all of the integral types can have
    > a size of 1.


    Interesting note.

    >> Now I have doubts only on 64-bit machines, where 'long int'
    >> may be that 'at least 32 bits', but it can be more also :p
    >> So if it can, sould it or not?

    >
    > All of the 64 bit machines I use have a 64 bit long.
    > It seems the most natural.


    For me too. But probably not for Microsoft: they use 32 bits
    for 'long int' on 64-bit architecture and use nonstandard
    [not for today version of C++ Standard] 'long long int' for
    64-bit integers in their compiler.
    I know the Standard doesn't require 'long int' to be the
    maximal size on a particular platform, so the 32-bit 'long int'
    is acceptable [thus stupid, for me]. But using 'long long int'
    for 64 bits and showing a finger to Standards when it's possible
    to use 'long int' for that, it's a mess IMHO.

    >> Here, I have some doubts on 64-bit platform. On 32-bit
    >> 'short' is mostly 16-bit and no more, because it should be
    >> able to be shorter than plain 'int'.

    >
    > That's not required. On word addressed machines (e.g. Unisys
    > 2200), it's probably the same as int. In fact, on a Unisys
    > 2200, I would expect short, int and long all to have 36 bits.


    Yes, I've thought '<=' but said '<' ;P My bad.

    >> I don't think emulating 'int' as two 8-bit registers to be
    >> the most convenient for the 8-bit platform to compute on
    >> integers :p

    >
    > It's more convenient that using even more bytes, and it is the
    > least the standard allows.


    OK, I've found the following example:
    http://www.z88dk.org/old/zcc.html#compdatat
    and it explained me a lot.
    Seems like the "emulation" is the way to go to implement the
    rules of Standard in practice, on non-32-bit platforms.

    --
    SasQ
    SasQ, Mar 30, 2007
    #12
  13. On 30 Mar, 02:31, SasQ <> wrote:
    > Dnia Thu, 29 Mar 2007 02:44:27 -0700, James Kanze napisa³(a):
    >
    > > C++ has nothing to say about the size of a machine word.
    > > All it guarantees is that char has at least 8 bits
    > > (but there have been implementations with 9, 10 and 32 bit
    > > chars, at least), that int is at least 16 bits
    > > (I've seen 16, 32, 36 and 48---and 24 wouldn't surprise me
    > > for some machines I've heard of), that long is at least 32
    > > bits, and the next standard will also require a long long of
    > > at least 64 bits.

    >
    > Is it sure for now?
    > Would there be 'long long long int' in a future then?


    You can get a copy of the working document for the next standard from
    the C++ Standard Committee's page [1]. There you can also get to read
    the proposals for new features and other information. If you does not
    have the standard available you can always try to get a copy of the
    draft closest to the standard.

    Anyway, on this neat little list [2] you can see that the long long
    type is part of the current working document and will thus be in the
    next standard.

    1. http://www.open-std.org/jtc1/sc22/wg21/
    2. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2122.htm

    --
    Erik Wikström
    =?iso-8859-1?q?Erik_Wikstr=F6m?=, Mar 30, 2007
    #13
  14. SasQ

    James Kanze Guest

    On Mar 30, 2:31 am, SasQ <> wrote:
    > Dnia Thu, 29 Mar 2007 02:44:27 -0700, James Kanze napisa³(a):


    > > C++ has nothing to say about the size of a machine word.
    > > All it guarantees is that char has at least 8 bits
    > > (but there have been implementations with 9, 10 and 32 bit
    > > chars, at least), that int is at least 16 bits
    > > (I've seen 16, 32, 36 and 48---and 24 wouldn't surprise me
    > > for some machines I've heard of), that long is at least 32
    > > bits, and the next standard will also require a long long of
    > > at least 64 bits.


    > Is it sure for now?


    About as sure as anything can be. C99 has it. C++ adopted it,
    partially at least on the grounds of C compatibility. Formally,
    the next version of the standard hasn't been adopted, and the
    committee could vote to remove it. Practically, I'd say that
    the probability of that happening is about as close to 0 as you
    can get.

    > Would there be 'long long long int' in a future then?


    I doubt it. The C committee adopted long long because it was
    already in wide-spread use. They recognized, however, that long
    long was not the right solution, because it doesn't scale, so
    they also provided a more generic solution for future expansion
    (which has also been adopted by the committee).

    > And where do you know that from?


    I'm a technical expert with the French national body (AFNOR),
    and participate in the standardization effort.

    [...]
    > >> Now I have doubts only on 64-bit machines, where 'long int'
    > >> may be that 'at least 32 bits', but it can be more also :p
    > >> So if it can, sould it or not?


    > > All of the 64 bit machines I use have a 64 bit long.
    > > It seems the most natural.


    > For me too. But probably not for Microsoft: they use 32 bits
    > for 'long int' on 64-bit architecture and use nonstandard
    > [not for today version of C++ Standard] 'long long int' for
    > 64-bit integers in their compiler.


    Every C++ compiler I know accepts long long today. It is part
    of the C standard, after all.

    > I know the Standard doesn't require 'long int' to be the
    > maximal size on a particular platform,


    It requires long to be the largest integral size.

    This lead to extensive debate in the C committee. There is a
    lot of C code out there doing things like:
    size_t s ;
    printf( "%lu", (unsigned long)s ) ;
    unsigned long is used, of course, because it was guaranteed that
    no larger integral type existed.

    The adoptation of long long broke such code. The C committee
    was not happy about that, but felt, in the end, that they didn't
    have much choice.

    In the next version of the C++ standard, there will be no
    requirement that long (or even long long) be the largest
    integral type available. A system with 128 bit words could
    still define long long to be a 64 bit type, and define a
    int128_t as well. In the future, if you want the largest
    integral type available, you will have to use intmax_t (defined
    in <stdint.h>, and in C++ <cstdint>). To write something like
    the above, you would have to include <stdint.h> and <inttype.h>,
    and write:
    size_t s ;
    printf( "%ju", (uintmax_t)s ) ;
    or:
    size_t s ;
    printf( "%zu", s ) ;

    > so the 32-bit 'long int'
    > is acceptable [thus stupid, for me]. But using 'long long int'
    > for 64 bits and showing a finger to Standards when it's possible
    > to use 'long int' for that, it's a mess IMHO.


    I don't think it a particularly wise decision either. But
    vendors don't like to break user code, even when it is already
    "broken"; presumably, they fear that there is some user code
    which depends on long being 32 bits.

    --
    James Kanze (GABI Software) email:
    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
    James Kanze, Mar 30, 2007
    #14
    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. Shailesh
    Replies:
    4
    Views:
    539
    Shailesh
    Apr 4, 2004
  2. ark

    sizeof C integral types

    ark, Jan 14, 2004, in forum: C Programming
    Replies:
    45
    Views:
    1,073
    Dan Pop
    Jan 19, 2004
  3. Army1987
    Replies:
    6
    Views:
    335
    CBFalconer
    Jul 7, 2007
  4. Ioannis Vranos
    Replies:
    13
    Views:
    490
    James Kanze
    Mar 10, 2008
  5. Ioannis Vranos

    Minimum sizes of integral and floating point types

    Ioannis Vranos, Mar 8, 2008, in forum: C Programming
    Replies:
    9
    Views:
    341
    Richard Heathfield
    Mar 9, 2008
Loading...

Share This Page