[serialization] two problems
Hi, after "cvs up" is run into two new problems with serialization. First is missing include, patch attached. The second is this: gcc.compile.c++ ../../../src/runtime/bin/gcc/debug/threading-multi/runtime_standalone.o In file included from /space/NM/boost/boost/archive/detail/iserializer.hpp:47, from /space/NM/boost/boost/archive/basic_binary_iarchive.hpp:36, from /space/NM/boost/boost/archive/binary_iarchive.hpp:21, from ../../../src/runtime/runtime_standalone.cpp:14: /space/NM/boost/boost/serialization/is_abstract.hpp:30: error: redefinition of `struct boost::is_abstract<T>' /space/NM/boost/boost/type_traits/is_abstract.hpp:130: error: previous definition of `struct boost::is_abstract<T>' The second patch addresses this problem, but I'd also suggest to remove boost/serialization/is_abstract.hpp to avoid further problems. This happens in CVS HEAD, but I suspect the same problems might be present on release branch, and so should be merged there. - Volodya
Could you send a little more context. This isn't happening in our tests.
/space/NM/boost/boost/archive/binary_iarchive.hpp:21, from ../../../src/runtime/runtime_standalone.cpp:14: /space/NM/boost/boost/serialization/is_abstract.hpp:30: error: redefinition of `struct boost::is_abstract<T>' /space/NM/boost/boost/type_traits/is_abstract.hpp:130: error: previous definition of `struct boost::is_abstract<T>'
The second patch addresses this problem, but I'd also suggest to remove boost/serialization/is_abstract.hpp to avoid further problems.
What about compilers which don't support is_abstract ? This would break serialization for all those compilers. Robert Ramey
Robert Ramey wrote:
Could you send a little more context. This isn't happening in our tests.
Just try a file containing two lines: #include <boost/type_traits/is_abstract.hpp> #include <boost/archive/binary_iarchive.hpp>
/space/NM/boost/boost/archive/binary_iarchive.hpp:21, from ../../../src/runtime/runtime_standalone.cpp:14: /space/NM/boost/boost/serialization/is_abstract.hpp:30: error: redefinition of `struct boost::is_abstract<T>' /space/NM/boost/boost/type_traits/is_abstract.hpp:130: error: previous definition of `struct boost::is_abstract<T>'
The second patch addresses this problem, but I'd also suggest to remove boost/serialization/is_abstract.hpp to avoid further problems.
What about compilers which don't support is_abstract ? This would break serialization for all those compilers.
Why serialization/is_abstract.hpp is in better position to handle such compilers then type_traits/is_abstract.hpp? I'm not saying that my patch is ideal, but having two headers for the same purpose is very bad idea, IMO. - Volodya
Vladimir Prus wrote:
Robert Ramey wrote:
Could you send a little more context. This isn't happening in our tests.
Just try a file containing two lines:
#include <boost/type_traits/is_abstract.hpp> #include <boost/archive/binary_iarchive.hpp>
I see the problem now.
Why serialization/is_abstract.hpp is in better position to handle such compilers then type_traits/is_abstract.hpp? I'm not saying that my patch is ideal, but having two headers for the same purpose is very bad idea, IMO.
agreed. Its just an oversight which requires some thought to fix. A little background. a) I need a type trait to determine whether or not a base class could be instanticiated. I believe I needed this to implement base_object. b) I found and implementation of is_abstract. It was interesting but only worked on some compilers. So I made serialization::is_abstract which defaulted to false. For compilers not supporting is_abstract and for portable code, is_abstract has to be overloaded. c) eventually, is_abstract got fixed up in such a way that for compilers not supporting it, it returns the result of is_polymorphic. I missed the discussion. So it has come to pass that the type_traits is_abstract and serialization is_abstract are different and have different defaults for non-conforming compilers. I only just found out about this problem, and I haven't had time to think about how to address it. Of course the type traits implementation isn't going to be very useful given that it silently gives the wrong result for many compilers. From my perspective, it would have been better to static assert if one tried to use is_abstract default on a non-conforming compiler. The problem should only occur in modules which include both serialization and type traits is_abstract. That fact might be of some consolation. Robert Ramey
Robert Ramey wrote:
Just try a file containing two lines:
#include <boost/type_traits/is_abstract.hpp> #include <boost/archive/binary_iarchive.hpp>
I see the problem now.
Why serialization/is_abstract.hpp is in better position to handle such compilers then type_traits/is_abstract.hpp? I'm not saying that my patch is ideal, but having two headers for the same purpose is very bad idea, IMO.
agreed.
Its just an oversight which requires some thought to fix. A little background.
a) I need a type trait to determine whether or not a base class could be instanticiated. I believe I needed this to implement base_object.
b) I found and implementation of is_abstract. It was interesting but only worked on some compilers. So I made serialization::is_abstract which defaulted to false. For compilers not supporting is_abstract and for portable code, is_abstract has to be overloaded.
c) eventually, is_abstract got fixed up in such a way that for compilers not supporting it, it returns the result of is_polymorphic. I missed the discussion.
So it has come to pass that the type_traits is_abstract and serialization is_abstract are different and have different defaults for non-conforming compilers. I only just found out about this problem, and I haven't had time to think about how to address it.
You can #ifndef BOOST_NO_IS_ABSTRACT, I believe.
Of course the type traits implementation isn't going to be very useful given that it silently gives the wrong result for many compilers. From my perspective, it would have been better to static assert if one tried to use is_abstract default on a non-conforming compiler.
Please note it's not "non-conforming" compiler. My understanding is that http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#337 which is used to detect abstract types, is not part of any official C++ standard, so compilers are not required to support this.
The problem should only occur in modules which include both serialization and type traits is_abstract. That fact might be of some consolation.
I'm afraid no, I don't include type_traits/is_abstract.hpp directly, and I have no idea how it's got included. I just get a compile error. - Volodya
Doug asked me to fix this. I fixed it on my machine, tested it with all my compilers, and checked into the release branch. Robert Ramey
participants (2)
-
Robert Ramey -
Vladimir Prus