"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.
And getting back to our filesystem example, if the interface states 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
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. 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. Robert Ramey