From: Jeff Garland (jeff_at_[hidden])
Date: 2007-05-28 11:10:26
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
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk