[serialization] problem with boost/serialization/is_abstract.hpp
In MSVC 6.0, the following snippet fails: #include <boost/archive/text_iarchive.hpp> #include <boost/tuple/tuple.hpp> 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 // 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 If nobody complains, I can fix this and commit it to the release and main branch. 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. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Peter Dimov ha escrito:
Joaquín Mª López Muñoz wrote:
The code is *incorrectly* using __MSVC_VER where it should use _MSVC_VER (just one leading underscore).
_MSC_VER.
Of course :) Thanks for the heads up. What worries me, again, is the potential redefinition problem explained in my previous post. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
1) I'm not going to complain about fixing this - thanks 2) This code addresses the issue that (last time I checked) boost/type_traits/is_abstract.hpp does not work on most compilers. The intention of this code is to use the boost one where it is known to work and to use one that returns false if is_abstract is not supported on the platform. I believe this code supports this intention. There might be a better way to do this. I don't know if there is a boost macro which does the job - maybe BOOST_NO_SFNAE. Anyone is free to weigh in on this. Robert Ramey "Joaquín Mª López Muñoz" <joaquin@tid.es> wrote in message news:4189EB3B.F3FB4D3D@tid.es... In MSVC 6.0, the following snippet fails: #include <boost/archive/text_iarchive.hpp> #include <boost/tuple/tuple.hpp> 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 // 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 If nobody complains, I can fix this and commit it to the release and main branch. 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. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Nov 04, 2004 at 08:56:29AM -0800, Robert Ramey wrote:
2) This code addresses the issue that (last time I checked) boost/type_traits/is_abstract.hpp does not work on most compilers. The intention of this code is to use the boost one where it is known to work and to use one that returns false if is_abstract is not supported on the platform. I believe this code supports this intention.
Not really. Or more precisely, your assumption where is_abstract is known to work is too broad. The problem is, is_abstract fails with gcc 3.4 for non-trivial examples. I reported this in <URL:http://lists.boost.org/MailArchives/boost/msg10998.php>. IIUC, this bug will be fixed in gcc 4.x, but not in the gcc 3.4 release series, cf. <URL:http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17232>. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
"Robert Ramey" <ramey@rrsd.com> writes:
I don't know if there is a boost macro which does the job - maybe BOOST_NO_SFNAE. Anyone is free to weigh in on this.
Warning: I have ignored the context of this discussion. BOOST_NO_SFINAE is a lie, at least in part. It is set for VC6 and VC7, but if you use the contents of boost/python/detail/enable_if.hpp you can get the effects of enable_if on those compilers. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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
Aleksey Gurtovoy wrote:
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.
I see an error with bcc32 if I use and xml_i/o archive and include my own XML parser which uses spirit in the same .cpp file. There error is to do with is_abstract but can't remember the exact error at the moment, but it may be the same problem. Thanks Russell
participants (7)
-
Aleksey Gurtovoy -
Christoph Ludwig -
David Abrahams -
Joaquín Mª López Muñoz -
Peter Dimov -
Robert Ramey -
Russell Hind