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

From: Jeffrey C. Jacobs (darklord_at_[hidden])
Date: 2002-10-03 09:09:30

Interesting!  Well, my department has .NET on order so hopefully I will be
able to get a new mangle document together soon.

In any case, my thought is whereas we KNOW __int<N> will always be N-bits,
it is MS that decides that int is 32 bits and therefore equivalent to
__int32.  I am sure __int32 will always be 32-bits but I think we agree int
on even an MS (e.g. Win64) system ints may not always be 32-bits (though up
until now they have stayed as such -- as another aside, since "int" is
suppose to represent the architecture's "most comfortable type", so to
speak, isn't int64 the best choice for int on a 64-bit machine?)  My main
worry is even though up until now __int64 has been 100% equivalent to long
long on most platforms, there may come a time and architecture where long
long represnets 128 bits, and equally so might long if int becomes 64
(though such a system is likely to implement (8, 16, 32, 64, 64) or (8, 16,
32, 64, 128) in practice), so althogh we come from different directions, we
agree that __int<N> and {signed char, short, int, long, long long} don't mix
when developing a generic integer.hpp.

Now, since MSVC++ v. 7.0 and above, clearly we don't even need __int<N>
specializations because they all map more or less 1:1 to the ISO types [+
long long].  Down the road, this may not hold.  We know there certainly is a
strange case for this legacy compiler.  Thus, my thought still stands:

1) For all other platforms, write int_least_helper in terms of the ISO types
[+ long long] only.
2) Use some kind of #if defined to allow it to be implemented in terms of
__int<N> ONLY on MS platforms (especially legacy and potentially for future
compatibility).  Since in v 7.0 these map 1:1 to ISO types anyway, having
such a definition on v 7.0 and above or the ISO types should not make any
difference as long as MS doesn't introduce "unique" types (__int128 for
instance when long long may still be 64-bits).
3) Let the client (boost user) on MS (at least for backwards compatibility)
decide if he or she prefers __int<N> or ISO types, mainly for use on legacy
compilers.
4) [Just to chime in some agreement] move int_least_helper to a detail
namespace so we don't need to second guess if people are using it directly
when we want to change it.

Interestingly enough, I have a theory on what the next integral type added
to the ISO language will be after "long long'...

"short short"!  After all, with short short, on a 64-bit arch, you could
have {char, short short, short, int, long, long long} be (8, 16, 32, 64,
128, 128) which might be logical in keeping with "int is arch-preferred
type" logic.

Jeffrey.

"John Maddock" <jm_at_[hidden]> wrote in message
news:022601c26acd$fbf87800$495c87d9_at_1016031671...
>
> I couldn't believe this at first, but after some investigating, you're
> right: on VC6 the __intXX types are distinct from the standard C++ types!
> However this has been fixed in VC7 - here __int32 is the same type as int
> for example (this is the same behaviour as on Borland and Metrowerks BTW),
> and in VC7.1 __int64 and long long are the same type.