Re: [boost] Re: Proposal for cleanup of INT64 macros

From: John Maddock (john_at_[hidden])
Date: 2004-10-15 06:01:41

> That's what BOOST_HAS_LONG_LONG and BOOST_HAS_MS_INT64 are for - see 
> is_integer for an example of use:
>
> template <class T> is_integral{...};
>
> template<> is_integral<unsigned char>{...};
> // etc
> #ifdef BOOST_HAS_LONG_LONG
> template<> is_integral<long long>{...};
> template<> is_integral<unsigned long long>{...};
> #elif defined(BOOST_HAS_MS_INT64)
> template<> is_integral<__int64>{...};
> template<> is_integral<unsigned __int64>{...};
> #endif
>
> Note these macros should only be used when overloading/specialising for 
> all intrinsic types, such usage should probably be infequent IMO.

I forgot to say: this use case is potentially more complex still:

1) It's only a matter of time before we see 128-bit integer types (assuming 
that their not here already), these will not necessarily be spelled "long 
long".
2) For platforms where sizeof(int) == 8 then one of int32_t or int16_t will 
be type "short", and the other will be some vendor specific type (I believe 
this is already the case on some Cray systems, but don't have the details, 
and we don't have a macro for this either... yet!).  I've seen someone half 
jokingly suggest "short short" for the name of this type :-)
3) There are two compilers (MSVC6 and compatible Intel versions), where 
__int8, __int16, __int32 are distinct types from the standard and same sized 
integral types (short, int etc).  Fortunately MS fixed that one with VC7.

In other words overloading/specialising on all intrinsic integer types is 
complex and in general the full case needs vendor specific code, sorry :-(

John.