At 08:09 PM 11/8/2004, Robert Ramey wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:001401c4c5ec$46ea4b10$6501a8c0@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
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
of that
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 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