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

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

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

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.

--Beman