[boost] Re: shared_ptr and serialization

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-21 00:04:20

Since posting this I realized that although it would address the issue of
code portability - it wouldn't guarentee archive portability.  Even though
the idea of some standard archive format is waaaaaaaaaaaaay off into the
future, this idea would conflict with it.  I presume someone would find this
to be an issue.

Robert Ramey

"Robert Ramey" <ramey_at_[hidden]> wrote in message
news:cno217$o2s$1_at_sea.gmane.org...
>
> 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
>