[boost] Re: Re: Why no long long support in integer::int_t?

From: Jeffrey C. Jacobs (darklord_at_[hidden])
Date: 2002-09-24 18:00:01

"Richard Hadsell" <hadsell_at_[hidden]> wrote in message
news:3D90E4D9.7FF4D2B9_at_blueskystudios.com...
> "Jeffrey C. Jacobs" wrote:
> >
> > Not to mention the DEC alpha [and likely many future compilers] would
> > typically use:
> > 1, 4?, 8, 8, 16
>
> Our (Compaq's) alpha compilers use 1, 2, 4, 8, 8 (char, short, int, long,
long
> long).

Cool!  Well, there is a good example of when long may be the same as long
long which does kind of prove my point that nothing is guarenteed, even
though long long on Compac's compiler has sizeof(long long) == 8.  I'd be
curious if anyone has an old copy of the MS compiler (Visual C++ 5.x IIRC)
that supported the Alpha, as I know it had an __int128 and by implication I
GUESS MS would have implemented "long long" as __int128 on the Alpha
compiler, but as you point out, it really is up to the Compiler
Manufacturer.  All we can assume is that char, short, int, long, long long
are all ascending.  That does not break the use of int_t<bits> as long as we
add "long long" first but I still say we should NOT assume sizeof(__int64)
== sizeof(long long) since I can almost guarentee if Stroustrup has anything
to do with it, if he allows "long long" to be added, he will allow it to be
greater or equal in size to long, meaning that a compiler COULD choose to
implement it in any number of ways that did not evaluate to 64 bits.  Yes, I
conceed that there is probably NO compiler / platform that defines "long
long" as anything OTHER than 64-bits, but I hope we can look longer-term in
keeping with the two concepts: ISO C++ ascending sized integrals and MS
"sized" integrals (__int<n>).  Of course, I accept if I am in the minority
of this opinion but having stated my case, that's all I can hope.  :)

But to be clear, IMHO whether you want "long long" or __int64 should IMHO be
an implementation detail of int_t<n>.  In other words, IMHO, on MS
platforms, int_t<n>::fast should produce __int<n> rounded up to a power of 2
(e.g. int_t<60>::fast => __int64), and on SGI, Compac Alpha, etc. that
support long long you would get int_t<n>::fast in {char, short, int, long,
long long} (e.g. int_t<60>::fast => long long /usually/).

[I am assuming that when MS sees __int8 or __int32 for instance it generates
a char, int anyway so having one compiler using one set of consistant
definitions and all others follow the standard (+ long long) does not bother
me.]

Anyway, thanks for listening!  :)

Jeffrey.