Boost logo

Boost :

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
> Postings on this thread have motivated me to think some more on this
> "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
> 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
> specific interface (std::tr1::share_ptr).
> I believe that in the longer run, something of this nature will be the
> viable solution to this and other similar problems.
> Robert Ramey

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