"Peter Dimov" <pdimov@mmltd.net> wrote
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. [snip] What this all boils down to:
- for an "std::" library, it probably should be possible to write a non-intrusive serializer;
I understand the point you're making, but I'm not sure I agree...yet. To dictate the serialization layout might coerce a particular implementation. In the case of boost::filesystem, there is a convenient string format that can be used as the serialized form that can be reparsed into any implementation. Does that hold for any serializable std:: library component? With std::complex, you can choose to serialize as either polar or cartesian coordinates and either implementation can interpret the other. The public interface of std::map exposes all of the key/value pairs in the map, so writing the key/value pairs when serializing is enough to recreate a map. Thus far, your statement holds, but I haven't thought about every serializable object in std::, so there may yet be problems. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;