Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk