Beman Dawes wrote:
At 05:01 PM 11/8/2004, Robert Ramey wrote:
... I think 1.32.0 should be released without any further changes or delay of any sort.
Rather than adding any code anywhere - I would prefer to see this considered at a more leisurely pace. I would like to see some consensus reached after a number of people have looked at the various alternatives.
Makes sense. As someone else suggested, we really ought to have a Boost-wide set of recommendations first.
To tackle the question of serialization, one first needs to decide whether the library is an interface description and a proof of concept implementation, or an "ordinary" library that will never have alternate implementations. In short, std:: or just boost::. An "std::" library (tuple, shared_ptr, filesystem?) needs to specify its external representation as part of the interface. This is mandated by the fact that users will - very likely - serialize its classes under implementation A and deserialize them under implementation B. This must work. A "just boost::" library may have an opaque external representation that is an implementation detail. What this all boils down to: - for an "std::" library, it probably should be possible to write a non-intrusive serializer; - a "just boost::" library can just dump its private members directly to the archive. 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. 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.