|
Boost : |
From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-08 20:09:15
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:001401c4c5ec$46ea4b10$6501a8c0_at_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.
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.
> 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.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk