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

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-10-15 17:53:04

> 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?

> 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