On Dec 8, 2005, at 9:52 PM, David Abrahams wrote:
Matthias Troyer <troyer@itp.phys.ethz.ch> 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