David Abrahams wrote:
Yes, it does, in theory. Reality isn't that bad. For every M, the archive author has already added the necessary overloads for every "fundamental" type that supports optimized array operations.
In most cases this shouldn't require a separate overload for every fundamental type, since the actual array serialization procedure is often the same for _every_ type that can use the optimization. But again, that's a question of how much work the archive author is required to do, so Robert may not consider it a valid argument.
I prefer enumerating the overloads explicitly, but you can use a single SFINAE'd overload.
However, our approach is designed to make it very easy and more foolproof to provide the necessary information for such a type: in Matthias' original design, a trait specialization; in the more recent design, an overload of optimize_array that returns mpl::true_. In your proposal you need a separate overload of save_sequence.
Providing a save_sequence overload is approximately the same amount of work as adding a partial specialization or an optimize_array overload.
Then you likely either have to duplicate the normal fast serialization procedure in your overload...
... which is not a problem for archives supporting your .load_array or .save_array protocol.
or you have to dispatch to something written by the archive author that may be named differently for every archive.
Quite right. save_sequence for char[] can cover "bitwise serializability", though.