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@rrsd.com> wrote in message news:cno217$o2s$1@sea.gmane.org...
Postings on this thread have motivated me to think some more on this
topic.
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:000a01c4ccd5$f1906910$6501a8c0@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