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