At 06:39 PM 11/8/2004, Peter Dimov wrote:
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 all makes a great deal of sense to me. that >the external representation of a fs::path is the std::string returned by
string(), then the library should provide support for just that...
The docs don't currently say that explicitly, but it is certainly true. In the internationalized version I'm working on now, there will also be some path traits data that is part of the internal state, and that will be exposed by an appropriate get function. The ability to serialize based on either the actual internal physical representation (for "just boost" libraries) or on a logical representation provided by member functions (for "std" libraries) is really cool, IMO. --Beman