Boost logo

Boost :

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:
>> 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
> 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 ;-)


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 !


Boost list run by bdawes at, gregod at, cpdaniel at, john at