Is it standard and practical to use long long types?

Discussion in 'C++' started by Matt, Apr 12, 2004.

  1. Matt

    Matt Guest

    Hi folks. Can you help with some questions?

    I gather that some types supported by g++ are nonstandard but have been
    proposed as standards.

    Are the long long and unsigned long long types still under consideration
    for the ANSI C and C++ standards? Are they likely to be accepted into
    the standards?

    Which compilers support those types, and which do not?

    In a general practical sense, is portability impaired for programs that
    use those types?

    Is there any good literature on standard techniques related to word size
    and portability?
    ________________________
    keywords: gnu gcc g++ borland turbo visual microsoft intel ISO ANSI
    compiler long long C C++ language standard
     
    Matt, Apr 12, 2004
    #1
    1. Advertising

  2. Matt wrote:
    > Hi folks. Can you help with some questions?


    Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right thing
    to do. While related, these languages are different enough that answers
    for one frequently don't apply to the other.

    >
    > I gather that some types supported by g++ are nonstandard but have been
    > proposed as standards.
    >
    > Are the long long and unsigned long long types still under consideration
    > for the ANSI C and C++ standards? Are they likely to be accepted into
    > the standards?


    long long (along with its variants) was added to C with the 1999 ISO
    standard. C++ had not been updated with new features since 1998 (a 2003
    update corrected and clarified the existing standard, but added nothing
    new), and does not include long long. I don't know the details, but I'm
    sure it has been discussed and may still be being discussed for
    addition. I'd be surprised if it was not included in the next version of
    the C++ standard.

    >
    > Which compilers support those types, and which do not?


    C99 compilers do. Other C and C++ compilers do not, unless through
    extensions.

    >
    > In a general practical sense, is portability impaired for programs that
    > use those types?


    I would say so. C99 support is rather narrow at the moment.

    >
    > Is there any good literature on standard techniques related to word size
    > and portability?


    I don't understand this question.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Apr 12, 2004
    #2
    1. Advertising

  3. Matt

    Malcolm Guest

    "Matt" <> wrote in message
    >
    > Are the long long and unsigned long long types still under
    > consideration for the ANSI C and C++ standards? Are they likely
    > to be accepted into the standards?
    >

    Traditionally an int is the size of a register, and registers can be used
    either to hold addresses or data, so void * is also the same size as an int.
    That rule of thumb is breaking down with 64-bit architectures, because
    integers usually represent real numbers (say, the number of employees in a
    company) and there are only a few cases where you need a number bigger than
    4 billion.
    long long looks like the most likely convention to emerge for the 64-bit
    type. However it will be a long time before 32-bit architectures become
    rare, or long long becomes so entrenched that they are forced to support it.
    >
    > Is there any good literature on standard techniques related to word > size

    and portability?
    >

    Not that I know of. The main reason for using a 64-bit type is to represent
    a size of memory, in which case you should use size_t. Just occasionally you
    will need 64 bits for another purpose (eg give the entire population of the
    world an id number). In that case there is no neat solution if the target
    compiler won't support 64-bit types - you will have to define a structure
    and write your own arithmetical routines. (In C++ it is easier because you
    can wrap into a class). typedefing long long is probably a good idea if you
    think this might happen.
     
    Malcolm, Apr 13, 2004
    #3
  4. Malcolm wrote:
    > "Matt" <> wrote in message
    >
    >>Are the long long and unsigned long long types still under
    >>consideration for the ANSI C and C++ standards? Are they likely
    >>to be accepted into the standards?
    >>

    >
    > Traditionally an int is the size of a register,


    Not on 8-bit machines. It's a recommendation, not a requirement.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Apr 13, 2004
    #4
  5. Matt wrote:


    > Are the long long and unsigned long long types still under consideration
    > for the ANSI C and C++ standards? Are they likely to be accepted into
    > the standards?


    The C standard has included [signed | unsigned] long long now into its
    4th year.

    Follow-ups set to comp.lang.c.
     
    Martin Ambuhl, Apr 13, 2004
    #5
  6. Matt

    Matt Guest

    Kevin Goodsell wrote:
    > Matt wrote:


    >> Is there any good literature on standard techniques related to word
    >> size and portability?

    >
    >
    > I don't understand this question.
    >
    > -Kevin


    Oh. Uh, well, people have to deal with the fact that for a given
    numerical type, different compilers have different precisions for the
    given type. They want the same code to work the same with all or many
    compilers. I am looking for descriptions of standard techniques for
    doing that.
     
    Matt, Apr 13, 2004
    #6
  7. Matt wrote:
    >
    > Oh. Uh, well, people have to deal with the fact that for a given
    > numerical type, different compilers have different precisions for the
    > given type. They want the same code to work the same with all or many
    > compilers. I am looking for descriptions of standard techniques for
    > doing that.
    >


    Well, the general technique is to know the required minimum ranges of
    the types and write code that doesn't rely on anything beyond those
    ranges. So if I need a variable that might exceed 32,767, I don't use an
    int. In many cases, additional precision beyond what is needed is not
    harmful, so choosing something guaranteed to be "wide enough" works just
    fine.

    When people have problems with the differences in precision that
    different implementations may use, it's usually because they want to do
    something that relies on variables using a particular representation and
    size. For example, writing a value out to a file as raw bits, and
    reading it back in later. The simple answer to this problem is "don't do
    that". A file written that way isn't portable anyway. The right thing to
    do is to define your file format, and write your program so that it
    handles that format (by reading & writing byte-by-byte and
    reconstructing/deconstructing values as you go if necessary -- though
    differences in the size of a byte could potentially cause problems).

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Apr 13, 2004
    #7
  8. Matt

    Matt Guest

    Kevin Goodsell wrote:
    > Matt wrote:
    >
    >>
    >> Oh. Uh, well, people have to deal with the fact that for a given
    >> numerical type, different compilers have different precisions for the
    >> given type. They want the same code to work the same with all or many
    >> compilers. I am looking for descriptions of standard techniques for
    >> doing that.
    >>

    >
    > Well, the general technique is to know the required minimum ranges of
    > the types and write code that doesn't rely on anything beyond those
    > ranges.


    OMG. Is this my punishment for cross posting?
     
    Matt, Apr 13, 2004
    #8
  9. Matt

    Jack Klein Guest

    On Tue, 13 Apr 2004 00:10:35 +0100, "Malcolm"
    <> wrote in comp.lang.c:

    >
    > "Matt" <> wrote in message
    > >
    > > Are the long long and unsigned long long types still under
    > > consideration for the ANSI C and C++ standards? Are they likely
    > > to be accepted into the standards?
    > >

    > Traditionally an int is the size of a register, and registers can be used
    > either to hold addresses or data, so void * is also the same size as an int.
    > That rule of thumb is breaking down with 64-bit architectures, because
    > integers usually represent real numbers (say, the number of employees in a
    > company) and there are only a few cases where you need a number bigger than
    > 4 billion.


    The correspondence in size between ints and registers has been broken
    in many, many platforms over the years, long before 64-bit
    architectures (other than Cray, perhaps) existed.

    The assumption that sizeof(void *) == sizeof(int) is horrible broken
    and a crutch for the uninformed or lazy, always has been, and always
    will be.

    I was working today, and will be for the next few weeks, on a platform
    with quite a decent C compiler where int has 16 bits and pointers have
    32. Not "far" pointers, but all pointers. At the hardware level,
    addresses have 32 bits and there is a 4Gb address space.

    --
    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, Apr 13, 2004
    #9
  10. Matt <> writes:
    > Kevin Goodsell wrote:
    > > Matt wrote:

    >
    > >> Is there any good literature on standard techniques related to word
    > >> size and portability?

    > > I don't understand this question.
    > > -Kevin

    >
    > Oh. Uh, well, people have to deal with the fact that for a given
    > numerical type, different compilers have different precisions for the
    > given type. They want the same code to work the same with all or many
    > compilers. I am looking for descriptions of standard techniques for
    > doing that.


    I've redirected followups to comp.lang.c.

    C99 provides a standard header, <stdint.h>, that provides typedefs for
    a variety of exact-width, minimum-width, and "fastest" signed and
    unsigned integer types.

    If your compiler doesn't support <stdint.h>, it's easy to implement
    for any C90 compiler (except that it may or may not support 64-bit
    types). See Doug Gwyn's public-domain q8 library, available at
    <http://www.lysator.liu.se/c/q8/>.

    Many pre-C99 compilers support "long long" and "unsigned long long" as
    an extension, though it's not certain that the corresponding printf
    formats will be supported by the library.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
     
    Keith Thompson, Apr 13, 2004
    #10
  11. Matt

    jacob navia Guest

    lcc-win32 supports long long. The non-standard
    __int64
    is supported to maintain compatibility with Microsoft Visual C.
    It is a 64 bit integer type
     
    jacob navia, Apr 13, 2004
    #11
  12. "jacob navia" <> wrote in message
    news:c5gs1j$cr9$...
    > lcc-win32 supports long long. The non-standard
    > __int64
    > is supported to maintain compatibility with Microsoft Visual C.
    > It is a 64 bit integer type



    Looking at the subject of your message, the answer is NO since there is not
    such a thing as long long type in C++. Next time do not cross post among
    irrelevant newsgroups, C & C++ are different languages.






    Ioannis Vranos
     
    Ioannis Vranos, Apr 13, 2004
    #12
  13. Matt

    Matt Guest

    Ioannis Vranos wrote:
    > "jacob navia" <> wrote in message
    > news:c5gs1j$cr9$...
    >
    >>lcc-win32 supports long long. The non-standard
    >>__int64
    >>is supported to maintain compatibility with Microsoft Visual C.
    >>It is a 64 bit integer type

    >
    >
    >
    > Looking at the subject of your message, the answer is NO since there is not
    > such a thing as long long type in C++. Next time do not cross post among
    > irrelevant newsgroups, C & C++ are different languages.
    >
    >
    >
    >
    >
    >
    > Ioannis Vranos
    >


    Next time reply to the same person you seem to be addressing.

    Next time don't post using weirdo fonts.

    Next time try to give a reply that is useful to somebody.
     
    Matt, Apr 13, 2004
    #13
  14. Matt

    Matt Guest

    Kevin Goodsell wrote:
    > Matt wrote:
    >
    >> Hi folks. Can you help with some questions?

    >
    >
    > Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right thing
    > to do. While related, these languages are different enough that answers
    > for one frequently don't apply to the other.


    I cross-posted because I am asking the questions about both languages.
     
    Matt, Apr 13, 2004
    #14
  15. Matt <> scribbled the following
    on comp.lang.c:
    > Ioannis Vranos wrote:
    >> "jacob navia" <> wrote in message
    >> news:c5gs1j$cr9$...
    >>>lcc-win32 supports long long. The non-standard
    >>>__int64
    >>>is supported to maintain compatibility with Microsoft Visual C.
    >>>It is a 64 bit integer type

    >>
    >> Looking at the subject of your message, the answer is NO since there is not
    >> such a thing as long long type in C++. Next time do not cross post among
    >> irrelevant newsgroups, C & C++ are different languages.


    > Next time reply to the same person you seem to be addressing.


    > Next time don't post using weirdo fonts.


    > Next time try to give a reply that is useful to somebody.


    Ioannis's post appeared just fine on my newsreader. Ioannis is using
    a Greek locale on his newsreader, as apparent from the ISO-8859-7
    charset in his NNTP headers, but his post does not use any characters
    from that charset. Perhaps your own newsreader insists on using
    "weirdo fonts" for any charset that is not ISO-8859-1?

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "You have moved your mouse, for these changes to take effect you must shut down
    and restart your computer. Do you want to restart your computer now?"
    - Karri Kalpio
     
    Joona I Palaste, Apr 13, 2004
    #15
  16. Matt

    Dan Pop Guest

    In <c5f7j3$pvd$> "Malcolm" <> writes:


    >"Matt" <> wrote in message
    >>
    >> Are the long long and unsigned long long types still under
    >> consideration for the ANSI C and C++ standards? Are they likely
    >> to be accepted into the standards?
    >>

    >Traditionally an int is the size of a register,


    This "tradition" has been broken so many times that it ceased being a
    tradition long ago. The standard simply doesn't allow it for 8-bit
    systems and it is very impractical for many 64-bit systems.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Apr 13, 2004
    #16
  17. "Matt" <> wrote in message
    news:OBDec.1479$...
    > Hi folks. Can you help with some questions?
    >
    > I gather that some types supported by g++ are nonstandard but have been
    > proposed as standards.
    >
    > Are the long long and unsigned long long types still under consideration
    > for the ANSI C and C++ standards? Are they likely to be accepted into
    > the standards?
    >
    > Which compilers support those types, and which do not?
    >
    > In a general practical sense, is portability impaired for programs that
    > use those types?


    Even a program using only long is not portable (in the sense that it will
    always work correctly).

    The only thing that the standard gaurantees (I can't find the reference) is
    that int is at least 32 bits.

    Therefore if you require an integer > 32 bits the only way for your program
    to be
    totally portable is to write your own 'BigInteger' class.

    Note that you can't even portably check stuff with the preprocessor because
    #if LONG_MAX < 73624963649249264926492
    Is just not going to work if LONG_MAX is only 2^31-1 (I would hope for a
    compiler error)

    If you limit portability to machines known to support 64 bits then it is
    near certainty that
    long will be 64 bits - but check with the preprocessor.

    If you want more than 64 bits you are unlikely to be portable to many
    machines whether the
    compiler supports long long or not.
    I would suggest that you try:
    #ifdef LONG_LONG_MAX
    (or LONGLONG_MAX? )


    >
    > Is there any good literature on standard techniques related to word size
    > and portability?
    > ________________________
    > keywords: gnu gcc g++ borland turbo visual microsoft intel ISO ANSI
    > compiler long long C C++ language standard
    >
     
    Nick Hounsome, Apr 13, 2004
    #17
  18. Matt

    Dan Pop Guest

    In <OBDec.1479$> Matt <> writes:

    >I gather that some types supported by g++ are nonstandard but have been
    >proposed as standards.
    >
    >Are the long long and unsigned long long types still under consideration
    >for the ANSI C and C++ standards? Are they likely to be accepted into
    >the standards?


    The C99 standard has adopted them, there is no C++ standard supporting
    them, AFAIK. Note, however, that the vast majority of C implementations
    in current use do NOT support the C99 standard. At best, they support
    a subset of C99 in extended mode. And, of course, each supports a
    *different* subset of C99.

    >Which compilers support those types, and which do not?


    It's not only a matter of compiler support, it's also a matter of
    library support (not every compiler comes with its own libraries).

    >In a general practical sense, is portability impaired for programs that
    >use those types?


    Yes. A C89 compiler *must* diagnose long long as a syntax error when
    invoked in conforming mode. And if you invoke it with extensions enabled
    you don't have much control over what other "goodies" you get along with
    the long long support and what parts of your program they can (silently)
    break.

    >Is there any good literature on standard techniques related to word size
    >and portability?


    Each C type has a guaranteed minimal range. If you can afford using only
    types whose minimal range is enough for your purposes, your application
    is portable.

    This is the most elegant approach, but not always the most practical
    (using long when you need a 32-bit type is wasteful on platforms with
    64-bit longs if you need very large arrays of that type).

    Since each implementation must define the range of each standard type
    in <limits.h> and <float.h>, you can use the preprocessor to discover
    the minimal types that satisfy your needs on a given implementation
    and use your own typedef names for them. Use your typedef's when
    declaring your own variables. The drawback is that the code becomes less
    readable when you don't know the exact type that is behind each variable
    and it is also fairly easy to introduce very obscure bugs, this way. So,
    restrict this approach to the variables that *really* need it.

    C99 comes with a standard set of such typedef's, so you may want to use
    the same names in your code, rather than reinventing the wheel. Have a
    look at the specification of <stdint.h>.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Apr 13, 2004
    #18
  19. Matt <> writes:
    > Kevin Goodsell wrote:
    > > Matt wrote:
    > >
    > >> Hi folks. Can you help with some questions?

    > > Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right
    > > thing to do. While related, these languages are different enough
    > > that answers for one frequently don't apply to the other.

    >
    > I cross-posted because I am asking the questions about both languages.


    Then it probably would have been better to post separately to each
    newsgroup, since you're really asking two separate (but indirectly
    related) questions.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
     
    Keith Thompson, Apr 13, 2004
    #19
  20. Matt wrote:

    > Kevin Goodsell wrote:
    >
    >> Matt wrote:
    >>
    >>> Hi folks. Can you help with some questions?

    >>
    >>
    >>
    >> Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right
    >> thing to do. While related, these languages are different enough that
    >> answers for one frequently don't apply to the other.

    >
    >
    > I cross-posted because I am asking the questions about both languages.
    >


    But they are different languages, so they are two different questions,
    with different answers. You wouldn't cross-post a message to a baking
    group and an astronomy group just because you had a question about each,
    would you?

    You'll annoy fewer people and get better results if you follow my
    advice. If nothing else, having two separate threads in different groups
    makes it easier to spot messages you didn't read yet, and it's generally
    less confusing for a number of reasons.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Apr 13, 2004
    #20
    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. Matt
    Replies:
    106
    Views:
    1,970
    Dan Pop
    Apr 19, 2004
  2. Greg Reese
    Replies:
    0
    Views:
    453
    Greg Reese
    Nov 28, 2005
  3. Bart C

    Use of Long and Long Long

    Bart C, Jan 9, 2008, in forum: C Programming
    Replies:
    27
    Views:
    853
    Peter Nilsson
    Jan 15, 2008
  4. Replies:
    163
    Views:
    3,356
  5. Peter
    Replies:
    8
    Views:
    338
    Jorgen Grahn
    Dec 29, 2012
Loading...

Share This Page