From: Jeff Garland (jeff_at_[hidden])
Date: 2005-08-30 09:33:11
On Tue, 30 Aug 2005 19:40:29 +1000, Martin Slater wrote
> > i) My current preference is boost/Y/serialization.hpp
> > ii) On the otherhand, the ones I personally did - shared_ptr and some
> > others have been put into boost/serialization/Y.hpp. This also applies to
> > the STL serialization - since there is not boost/stll/... in any case.
> > b) He should include tests. But where should he put them? The current
> > situation mirror that of the above. The current method of making the
> > library maintainer responsable for making tests pass wouldn't attribute the
> > responsablity to the appropriate party
> This is only applicable where serialization can be implemented
> efficently from the public interface. With boost::dynamic_bitset in
> particular it's much more efficient to implement internally
> otherwise you need to iterate over the elements into a temporary
> structure , serialize it then reverse on load, whereas internally it
> is just a vector + used count. In these cases then it must(?) be the
> library maintainer thats responsible for acceptance. Anything else
> should probably be reviewed and accepted / rejected by you as that
> is where the complaints will be undoubtbly directed in case of
My suggestion, at the end of the review, was that serialization code for other
boost types should go in the library that provides the type and not in
serialization itself. This means that serialization can be extracted from
Boost without dragging in dependencies on date-time, multi-index, etc, etc.
That is, serialization doesn't wind up with links to all the rest of boost.
Instead it is the other way around. And users can easily avoid the
serialization dependency by not including serialization headers for the
> > c) Is any documentation necessary? - where should it go?
> My vote would be with the applicable library.
Also what we decided before. For example:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk