[boost] Re: Re: Re: [fileststem]1.32: withserilization:visibility ofm_path

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
more.
Some comments below.

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:001401c4c5ec$46ea4b10$6501a8c0_at_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.

OK - I see this now.

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

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.

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