Robert Ramey wrote:
I actually don't want to get into a discussion of which non-intrusive design is best. The social and code interoperability dynamics of any non-intrusive design are the same, and that's really what I want to discuss. Please let me know when you're ready to talk about that.
Sorry, I don't even know what that means.
Social dynamics aside, one point is that any intrusive design, no matter how clever, will always be more intricate and complex than it needs to be if the library doesn't provide a bit of help. But let's put complexity aside for a moment and just think about the problem from the perspective of a programmer that needs to provide serialization support for his class X. It so happens that X holds a contiguous array of char. The programmer knows that for some archives it can be a major performance gain to invoke their char[]-writing method, but he doesn't know which these archives are. Some of them may not have been written yet. So we need to give these programmers a _documented_ function that they can call when they serialize arrays. And it is best for this function to be described in the documentation of the serialization library, because that's what these programmers are using. They aren't writing archives or archive adaptors, they may not have heard of Dave's enhancements; they just serialize their own type. Whether this function should be named save_array and only accept (pointer, size) arrays, or save_sequence and accept arbitrary (iterator, size) sequences (as I proposed), is a matter of debate, but it doesn't change the fundamental point. The serialization library should provide a function that class authors can call when they serialize arrays... ... because no one else can. Now, if we add this function to the library, the next logical step is for the library to use its own function when serializing arrays, std::vector and std::valarray. It would be pretty odd not to do so. :-) We (*) can propose a complete list of changes to the library if you are interested, so that you can evaluate its impact. The support for objects without a default constructor does complicate matters a bit in the std::vector case, but it can be done. Existing binary archives should receive a significant speedup in the char[] case without any changes to the external archive format. (*) Hopefully the rest of the "we" agrees.