Janek Kozicki wrote:
Sebastian Ramacher said: (by the date of Mon, 28 May 2007 16:47:49 +0200)
As of version 1.34, Boost.PtrContainer supports serialization as defined by Boost.Serialization. Now I'd like to propose a switch to disable this feature. The attached patch adds checks if BOOST_PTR_CONTAINER_NO_SERIALZATION is defined around the serialization related code blocks and enables/disables serialization support.
It's not that I don't like serialization support but on a Debian system you have to install libboost-serialization-dev and libboost-serialization1.34.0 just to use Boost.PtrContainer.
That's an interesting problem.
What should be the policy about serialization support:
1. the serializaiton support is written in a boost library outside of boost::serialization (the case here),
Yes -- because we want the serialization code located 'near' the details of the types being serialized. The authors of these libraries understand the underlying structures and how best to serialize them. If the structures change the serialization might change so then we would have to coordinate cross-library updates.
2. or should it be written only inside the boost::serialization library (frequent case with other libraries). So that a non-serialization library will not pull serialization by header dependencies...
?
Nope. See my other response. With non-intrusive serialization the dependency on serialization can be strictly optional and up to the user. This is the best of both worlds. Note that there may be some libs where this is harder to do (multi-index), but I believe this is the approach we should aspire towards. Jeff