Boost logo

Boost :

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
>> 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
>the particular class implementtion. To do so will often result in a less
>than optimal
>> And getting back to our filesystem example, if the interface states
>> external representation of a fs::path is the std::string returned by
>> string(), then the library should provide support for just that, but in
>> 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.
>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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at