Peter Dimov-2 wrote
Stephen Kelly wrote: Note, by the way, that boost/serialization/array.hpp doesn't just implement serialization for boost::array; it also defines boost::serialization::array and implements serialization for std::array. So it doesn't belong to Array anyway.
this is the result of naming issues. the word array has been used for boost::array, std::array and the built-in C/C++ array. They all ended up in the same header so that one could find them when they were needed. the same applies to serialization of all the std library items. From my standpoint they should be in some separate place. but it's been of small consequence so they are where they are.
boost/serialization/optional.hpp and boost/serialization/variant.hpp are another story.
I never wanted these here. I wanted them to in their respective libraries but no one was willing to maintain them. At the time - I assume it's still true, we had a maintainer assigned to a module. We don't really have the concept of a maintainer handling part of a some module. I would be happy to must move option, variant (I think there's another one also) in to the respective library and be done with it. Probably low risk anyway because changes in he serialization library haven't broken any serialization implementation for a long, long time.
But only after there's a lightweight way to implement serialization.
I'm not sure what that refers to. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/type-traits-Rewrite-and-dependency-free-v... Sent from the Boost - Dev mailing list archive at Nabble.com.