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