Boost logo

Boost :

From: Matthias Troyer (troyer_at_[hidden])
Date: 2005-12-08 17:39:49


On Dec 8, 2005, at 9:52 PM, David Abrahams wrote:

> Matthias Troyer <troyer_at_[hidden]> writes:
>
>> I see two ways how this can be implemented and wanted to discuss what
>> option is best in your opinion:
>>
>> i) the load function for std::vector could dispatch to either version
>> A or B depending on the type traits has_trivial_constructor<T>
>
> ia) define the has_default_constructor<T> trait, which by default
> is derived from has_trivial_constructor<T> on implementations
> without magic compiler support.
>
>> ii) one could leave std::vector serialization untouched, meaning
>> always use version A, and use the optimized version B only in the
>> archive wrapper for archives implementing fast array serialization.
>> The advantage of this is that these archives know for which types
>> they provide fast array serialization, and could override the
>> std::vector serialization just for these types.
>
> That one scares me a lot. The archive author doesn't know the full
> range of element types T for which vector<T> can be
> fast-array-serialized, does he? What happens when I invent a new POD
> that I want to stick in vectors that will be serialized? Do I have to
> go modify the archive? Or have I misundestood this altogether?

Since the archive implements the fast array serialization for these
types, it has to know for which types it should be used. After all
that's what the use_array_optimization lambda expression member of
the archive in your proposal was for. For all these types it is safe
to first resize() the array and then do the appropriate fast
deserialization, while for other types he safe default (de)
serialization of std::vector can be used.

Regarding your question what happens when someone invents a new POD,
the answer in case of your proposal applied to MPI archives is that
you have to specialize the is_mpi_datatype<T> traits class for your
type T, since the lambda expression there is:

     typedef is_mpi_datatype<mpl::_1> use_array_optimization;

The same lambda expression can also be used with the array wrappers.

Actually, using has_default_constructor<T> scares me more, since a
user might (for some strange reason) have overloaded
save_construct_data although the type is default constructible.
Although this is not forbidden by the library, although I do not see
any reason why somebody would do. But in case someone has done it,
using has_default_constructor<T> to decide whether the current
version of vector serialization, or a new version using the array
wrapper is used will break backward compatibility. I believe that
nobody will have done that, but it scares me more than the point that
you raise.

Matthias


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