From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-09 12:44:45
I've had a little more opportunity to digest this post and now appreciate it
Some comments below.
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
> 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
OK - I see this now.
> A "just boost::" library may have an opaque external representation that
> 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 - agreed
> Specifically, the current scheme for serializing a boost::shared_ptr is
> suboptimal, because it can't be used with another implementation of
rather than "suboptimal" - I would characterise it as a "just boost"
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.
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk