Re: Is it standard and practical to use long long types?

From: Nick Hounsome (nh002_at_blueyonder.co.uk)
Date: 04/13/04 

Date: Tue, 13 Apr 2004 17:57:35 +0100

"Matt" <matt@themattfella.zzzz.com> wrote in message
news:OBDec.1479$TW6.711@news01.roc.ny...
> 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
>

Relevant Pages

  • Re: Is it standard and practical to use long long types?
    ... > proposed as standards. ... If you limit portability to machines known to support 64 bits then it is ... compiler supports long long or not. ...
    (comp.lang.c)
  • Re: Garbage Collection - Stop Making Trash
    ... Try moving Unix headers to Windows, ... attempt to sabotage portability -- we achieve limited portability ... except that no standards committee has endorsed an interface ... Microsoft loves this mentality. ...
    (comp.lang.cpp)
  • Re: which tutorial to use?
    ... compilers in existence that fully support C99. ... said, of course, none of those implementations _are_ conforming. ... there are large portions of both standards (regardless of what level ... portability, ...
    (comp.lang.c)
  • Re: code optimiation
    ... considers "portability", in whatever form you mean, to be the main goal ... programming since before you were born - merely since you were about 5 ... You are even trying to argue about C standards with people who ... - we write code that works on actual targets, compiled with real compilers, not some theoretical pure standards-compliant complier. ...
    (comp.arch.embedded)
  • Re: Report enhancements
    ... >issues are involved in portability. ... >> standards process was created as a means to that end. ... standardized) and in favor of CSV ASCII text. ... >> They also recognize transfers to and from Web sites. ...
    (comp.lang.cobol)