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

From: John Maddock (john_at_[hidden])
Date: 2004-10-16 05:23:00

>> There seems to be a lot of confusion about these macros, so let me try 
>> and
>> give you the full lowdown:
>
>> BOOST_NO_INT64
>
>> Indicates that boost::int64_t and boost_uint64_t do not exist in
>> boost/cstdint.hpp.  It's a defect macro because these types are 
>> documented
>
>> as existing; it doesn't indicate a defect in the compiler, although if
>> we're being picky, neither these types nor *any* of the exact width types
>> in boost/cstdint.hpp are required to be supported by C99.  If you need a
>> 64-bit integer type then this macro is the one to check (and then use
>> [u]int64_t).
>
>> Note these macros should only be used when overloading/specialising
>> for all intrinsic types, such usage should probably be infequent IMO.
>
> This is exactly my problem with polymorphic_(i/o)archive.hpp.  Its an
> interface class that redirects save/load for all intrinsic types to the
> implementation in a derived class.  Among the intrinsic types considered 
> is
> long and int64 (long long is not considered - the name suggested a 
> compiler
> dependent kludge). Currently I use BOOST_NO_INT64 but now I see that this
> fails on at least one machine where apparently int64 is a typedef or macro
> for long.  In this environment I get a compile error because a rather than 
> a
> function overload I get a compiler error with function redefinition.
> Before, I had a homemade BOOST_NO_INTRINSIC_INT64_T which seemed to work.
>
> What is the best thing to do in this situation?

Yes, use of BOOST_NO_INT64 will fail for the reasons you site, using:

#ifdef BOOST_HAS_LONG_LONG
// long long overload:
#elif defined(BOOST_HAS_MS_INT64
// __int64 overload:
#endif

Is the right way to go, and as I explained in another message, these may not 
be the only vendor specific types available, but are the only ones we know 
how to detect.  Oh, and don't forget that long long may have more or less 
than 64-bits (in case that matters to you).

John.

>> The macros BOOST_NO_INTRINSIC_INT64_T and BOOST_NO_INTRINSIC_UINT64_T
>> appear to have been removed, so no cleanup necessary :-)
>
> :-(  It seems that this is just what I need.  I didn't realize it existed 
> as
> I just depended on the information in the documentation and didn't look at
> the config.hpp file.
>
> Robert Ramey
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>