Re: [boost] Re: Re: Re: [fileststem]1.32: withserilization:visibility ofm_path

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-11-08 21:48:45

At 08:09 PM 11/8/2004, Robert Ramey wrote:
 >
 >"Peter Dimov" <pdimov_at_[hidden]> wrote in message
 >news:001401c4c5ec$46ea4b10$6501a8c0_at_pdimov2...
 >
 >> 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.
 >
 >In general, serialization for any class is specific to that class
 >implementation.  I don't think
 >makes sense to require that a serializtion implementation be independent 
of
 >the particular class implementtion.  To do so will often result in a less
 >than optimal
 >implementation.
 >
 >> 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.
 >
 >By requiring that fs::path expose enough of its state to be serializable.
 >This
 >can be done either with an appropriate friend declaration or by making
 >somethings public.

The key point is that fs::path makes its state public not by having public 
data members, but by having a public member function (string()) which 
returns enough information to reconstruct the actual internal state.

There are at least two possible useful internal implementations of fs::path 
that I can think of. One is the current implementation, which holds 
internal state in a std::string.

The other implementation would be to hold state as a std::vector of 
std::strings, where each string is one path element. This implementation 
would actually speed the decomposition functions and iteration over the 
elements. It might be particularly appropriate on an operating system like 
VMS where the O/S's path syntax is quite different from the portable 
syntax.

Again in the case where the O/S's native path syntax is quite different 
from the portable syntax, an implementation might also choose to keep an 
additional internal string which contained the path in the native format.

But regardless of which internal implementation is used, the path can 
always be completely represented by the string returned by 
fs::path::string(), and so that allows serialization to be completely 
independent of the internal implementation. The path can always be 
reconstructed by a constructor given the string.

So the use case Peter mentioned where path implementation A is serialized 
out to disk, and then reloaded later into path implementation B should 
always work.

--Beman