Re:Re: [boost] Proposal for cleanup of INT64 macros
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
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
participants (2)
-
John Maddock -
Robert Ramey