Boost logo

Boost :

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
> work.

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
> 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.

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.

Robert Ramey

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