Joaquín Mª López Muñoz writes:
In MSVC 6.0, the following snippet fails:
#include <boost/archive/text_iarchive.hpp> #include <boost/tuple/tuple.hpp>
A straightforward #include <boost/type_traits/is_abstract.hpp> would do as well.
int main() { return 0; }
complaining about is_abstract being already defined. The problem lies in the following lines inside boost/serialization/is_abstract.hpp:
#ifndef BOOST_TT_IS_ABSTRACT_CLASS_HPP #if defined(__GNUC__) && (34 <= _GNUC__ * 10 + __GNU_MINOR) \ || defined(__MSVC_VER) && (1310 <= __MSVC_VER) \ || defined(__EDG_VERSION__) \ /**/ #include <boost/type_traits/is_abstract.hpp> #else
First of all, the whole thing is a huge hack and can cause an ODR violation on 1-2-3. We should really fix type_traits to fall back to something like the code below, but that is definitely out for the release. Having said that, the #else branch is simply missing this: # define BOOST_TT_IS_ABSTRACT_CLASS_HPP
// default to false if not supported namespace boost { template<class T> struct is_abstract { typedef mpl::bool_<false> type; BOOST_STATIC_CONSTANT(bool, value = is_abstract::type::value); }; } // namespace boost #endif #endif // BOOST_TT_IS_ABSTRACT_CLASS_HPP
The code is *incorrectly* using __MSVC_VER where it should use _MSVC_VER (just one leading underscore). Thus boost::is_abstract is defined twice, as boost/type_traits.hpp is implicitly included by boost/tupe/tuple.hpp
It's getting defined twice because of the missing define above, not because of the misspelling, but the latter would be good to fix, too.
If nobody complains, I can fix this and commit it to the release and main branch.
Please! Together with the #define, if you can.
What worries me, though, is that the code above seems flawed to me (apart from the minor typo). What happens if the compiler is not one of those taken care of explicitly in boost/serialization/is_abstract.hpp? Could anyone please test the first snippet in some compiler other than MSVC, ICC for Windows, GCC or an EDG-based compiler? My thesis is that it will fail.
Surely fails on Borland, for the same reason. -- Aleksey Gurtovoy MetaCommunications Engineering