Re: [boost] Re: Re: [fileststem]1.32: withserilization:visibility of m_path

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 
work.

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 
non-intrusive serializer;

- a "just boost::" library can just dump its private members directly to the 
archive.

Specifically, the current scheme for serializing a boost::shared_ptr is 
suboptimal, because it can't be used with another implementation of 
std::tr1::shared_ptr.

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.