I've had a little more opportunity to digest this post and now appreciate it more. Some comments below. "Peter Dimov" <pdimov@mmltd.net> wrote in message news:001401c4c5ec$46ea4b10$6501a8c0@pdimov2...
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
OK - I see this now. the
archive.
OK - agreed
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
rather than "suboptimal" - I would characterise it as a "just boost" shared_ptr implementation. Actually I only recently became aware that shared_ptr interface might be part of the standard library. I would hope that such an interface has functionality exposed to permit it's serialization to depend solely upon its interface. I don't know what this would entail. 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.
Apparently, it has done just that. Robert Ramey