|
Boost : |
From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-20 13:22:34
Postings on this thread have motivated me to think some more on this topic.
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:000a01c4ccd5$f1906910$6501a8c0_at_pdimov2...
> Robert Ramey wrote:
> > Alternatively, you might want to consider expanding the shared_ptr
> > interface with enough information to permit serialization to be
> > implemented via the public interface.
> How, exactly? The current public interface is good enough for my
> serialization/deserialization needs,
I don't know that your needs are the same as everyone elses. The list of
everyone else's needs is very long and varied and was the key obstacle to
getting any serialization library even considered - let alone accepted.
> but I'm willing to consider your suggestions.
Here's another idea:
require that std::tr1::shared_ptr support the following interface as a
member template function:
template<class Archive, class T>
void serialize(Archive &ar, share_ptr<T> &t);
where Archive is a class that is required to provide the following member
functions
template<class T>
Archive & operator<<(const T &t);
template<class T>
Archive & operator>>(T &t);
template<class T>
Archive & operator&(T &t);
for any type T
I realize that such a suggestion may seem outlandish, premature and lots of
other things. But it is not fundamentally any more arbitrary than the
requirement that a serialization library include the
interfaces/functionality to support serialization of a shared_ptr through a
specific interface (std::tr1::share_ptr).
I believe that in the longer run, something of this nature will be the only
viable solution to this and other similar problems.
Robert Ramey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk