From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-08 18:39:54
Beman Dawes wrote:
> At 05:01 PM 11/8/2004, Robert Ramey wrote:
>> I think 1.32.0 should be released without any further changes or
>> delay of any sort.
>> Rather than adding any code anywhere - I would prefer to see this
>> considered at a more leisurely pace. I would like to see some
>> consensus reached after a number of people have looked at the
>> various alternatives.
> Makes sense. As someone else suggested, we really ought to have a
> Boost-wide set of recommendations first.
To tackle the question of serialization, one first needs to decide whether
the library is an interface description and a proof of concept
implementation, or an "ordinary" library that will never have alternate
implementations. In short, std:: or just boost::.
An "std::" library (tuple, shared_ptr, filesystem?) needs to specify its
external representation as part of the interface. This is mandated by the
fact that users will - very likely - serialize its classes under
implementation A and deserialize them under implementation B. This must
A "just boost::" library may have an opaque external representation that is
an implementation detail.
What this all boils down to:
- for an "std::" library, it probably should be possible to write a
- a "just boost::" library can just dump its private members directly to the
Specifically, the current scheme for serializing a boost::shared_ptr is
suboptimal, because it can't be used with another implementation of
And getting back to our filesystem example, if the interface states that the
external representation of a fs::path is the std::string returned by
string(), then the library should provide support for just that, but in the
meantime, it should be possible for the end user to non-intrusively
serialize a fs::path by defining an appropriate serialize(Archive&,
fs::path&, unsigned long) overload.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk