David Abrahams wrote:
Your responses to Matthias about fast array serialization certainly gave me the impression that you're brushing off valid arguments in a very cavalier manner. Further, IIRC, you ignored his last question:
Shall the serialization library documentation encourage the implementors of those functions to make use of array serialization features when available, or not?
This is likely to lead to something very distasteful, like a semi-official branch of the serialization library that works the way we need it to.
Hmm - I can't imagine why anyone would want to do that. Someone might want to make thier own derivation(s) of one or more archive classes or even a whole new archive class - but that doesn't represent any conflict with the current library.
We are working on a library for parallel computing that uses the serialization library to ship data via MPI. If you reject the proposed integration of fast array serialization into the library, we will need to encourage 3rd-party authors of serialization for types containing arrays to use some non-standard fast mechanism ...
of course this is what I haven't seen. I would expect that a "fast...archive" would include the specific functionality for certain types. Then users of those types with those archives would automatically benefit from the specialized functionality while preserving compatibility with other archive types. this has been done before - for example strings are serialized differently in some archives as opposed to others. I havn't seen anythiing differentabout this situation.
Every way we can think of to accomplish that eventually leads to something that feels like "hijacking" the library. We _really_ don't want to do that.
OK - I'll take another look at mattias code and see what can be done. Robert Ramey