Robert Ramey wrote:
Ian McCulloch wrote:
Is the bitwise_?archive_adaptor supposed to be useful for anything other than a native binary archive?
This is an alternative way of implementing the save_binary optimization. Application of this adaptor to any existing archive class will create a new archive class that includes the save_binary optimization. So it could be applied to say a, text_oarchive. But of course it would make no sense to do this as it would result in a slower archive (in text archives, save_binary renders binary output as base64 text). Also, saving data as bitwise binary maintains the representation of the host machine so the application of this adaptor would result in an archive which would be non-portable accross machines.
Ok. Would it be correct to describe the adaptor's function as overriding serialization for a particular type (or set of types) and serializing it in a different format, using facilities already available to the archive(s) ? It is clear that bitwise_serializable_adator, even when applied to a native binary archive will, in general, produce an archive that is incompatible with the base archive (say, if the user marks some POD type as bitwise_serializable, and the POD type contains some padding). Thus, I agree this belongs firmly in the class 'adaptor' - the resulting archive is distinct from the base archive. I can even imagine that there are some interesting uses for it. So I apologise for some of the language I used in my previous post, it was out of line. As far as I can tell, what distinguishes the 'adaptor' case from the array extensions that have been discussed at length, is 1. In the default case the save_array() function (**) reproduces the existing behaviour. That is, an array_adaptor<Base> would produce a bit-for-bit identical archive to using the Base archive type itself, for all Base archives that currently exist in the serialization library. 2. In the non-trivial case where save_array() does something different to the default, it needs to invoke functionality that does _not_ already exist in the serialization library, and is _archive_ _specific_. Both of these points strongly suggest, to me at least, that the save_array() extension is not properly an adaptor. Do you have a different interpretation? (**) Just for the record, I agree with Peter Dimov that something like save_sequence(Iterator, size) is better. This is needed for archives that directly support arrays as a distinct structure, if you want to serialize say a deque using the archive array format. Regards, Ian