[boost] Re: Proposal for cleanup of INT64 macros

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2004-10-15 15:38:24

John Maddock wrote:
>> Does a Boost.Config user really have to check all these different 
>> spellings of 64 bit types like for example:
>>
>> #ifdef BOOST_HAS_LONG_LONG
>>   support long_long_type
>>   support ulong_long_type
>> #elif defined(BOOST_HAS_INT64_T)
>>   support int64_t
>>   support uint64_t
>> #elif defined(BOOST_HAS_MS_INT64_T)
>>   support __int64
>>   support unsigned __int64
>> #endif
> 
> 
> NO!!!!!!
> 
> Just check BOOST_NO_INT64_T after including <boost/cstdint.hpp> and then 
> use [u]stdint_t if you want a 64-bit integer type.

Sounds good. "Assertion":

"The existence of _any_ 64-bit integer type implies the definedness of 
[u]int64_t and in this case the macro BOOST_NO_INT64_T is not set."

Correct ?

>> The example assumes there is only one signed/unsigned pair of 
>> intrinsic 64 bit integers - as I mentioned before I have no idea if 
>> this is always the case.
> 
> 
> Do you mean more than one type? If so then yes there may be many 64-bit 
> integral types - especially if int or long are 64-bit types.

I meant: "... more than one unsigned/signed pair of 64-bit wide types 
with distinct identities".

>> Consider the "support for type" in this example is in fact something 
>> like template specialization or overloading a function, where it would 
>> trigger an ambiguity situation using separate #if(n)defS ...
> 
> 
> 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.

Indeed. Unfortunately I have to overload for all intrinsic types ;-( , 
that's why I ask these strange questions.

(After reading your following post and 'is_integral.hpp', I figure 
working around it with 'is_integral' - although unhandy in my particular 
situation - may be the lesser of two evils...)

>> However, is there a possibility to reduce the painful work a user has 
>> to go through to support 64 bit types properly, somehow (probably by 
>> using a typedef alias like done for long_long_type, already) ?
> 
> 
> I doubt it, and it's not painful once you get your head around what the 
> macros actually mean, honestly ;-)

Agreed.

How does Boost.Config provide me with information how these types behave 
in integral promotion/conversion, then ?

Just kidding ;-) ...

Thanks a lot for your help !

Tobias