From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-11-08 22:01:43
At 06:39 PM 11/8/2004, Peter Dimov wrote:
>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
>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
>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
That all makes a great deal of sense to me.
>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
>string(), then the library should provide support for just that...
The docs don't currently say that explicitly, but it is certainly true. In
the internationalized version I'm working on now, there will also be some
path traits data that is part of the internal state, and that will be
exposed by an appropriate get function.
The ability to serialize based on either the actual internal physical
representation (for "just boost" libraries) or on a logical representation
provided by member functions (for "std" libraries) is really cool, IMO.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk