Robert Ramey wrote:
Now assume that we don't have plugins and applications written by the same developer, but just a shared library. Say, I want to write a library for manipulating EBNF grammar and want to add serialization. Client applications are not written by me at all. Now if that application defines a new archive type, nothing will work. Not to mention that I'm not happy with bloating my library with code for 5 archive types (binary, text, xml + wide variants of the latter two).
For this we have the polymorphic_ archives. Compile once with the polymorphic archive headers. Now your code is compatible with all archives past and future. At least that is my intent. Is there some reason this doesn't work as intended? Note that your serialization code contains code for only one archive - the polymorphic archive. There is no instantiation of code for the other archive classes. The only cost is a teensy bit of execution time as as archive calls are redirected through a vtable.
Exactly. Now consider that I have a .cpp file that has BOOST_CLASS_EXPORT. I don't know what kinds of archives will be used to serialize classes defined in .cpp. So, I need to *always* #include polymorphic_archive headers. If I don't include polymorphic archive, I'd need to include all standard archive types (again, I have no idea which archive type will be actually used), and that will instantiate a lot of code. Why not make include polymorphic_archive automatic? And make other archive types resort to polymorphic_archive when no serialization for that archive type was BOOST_CLASS_EXPORTED. As you say, the only cost is a "teensy bit of execution time", in most cases users won't even notice, but the code size will be reduced. - Volodya