Re: [boost] [serialization] Enhancing Archives with Archve Adaptors

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-11-27 06:59:11

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.