Re: [boost] [serialization] BOOST_CLASS_EXPORT worries

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-07-07 10:51:33

Vladimir Prus wrote:
>>> I recall that I did suggested one approach. BOOST_CLASS_EXPORT can
>>> register the class with all previously included archives and,
>>> unconditionally, with polymorphic archive. During saving, you can
>>> check if the saved class is registered with specific archive type.
>>> If not, you wrap archive in polymorphic archive and save. That would
>>> be slower, but in most situation extra virtual function call won't
>>> be a practical problem.
>>
>>> In the rare case where it will be a problem, user can:
>>> 1. Include necessary archive headers
>>> 2. Invoke BOOST_CLASS_EXPORT *again* in his module, after including
>>> another archive header. If BOOST_CLASS_EXPORT tolerates multiple
>>> invocations, this will instantiate the code for the needed archive
>>> type, and make saving to that archive type go without polymorphic
>>> arhive.
>>
>> export.hpp is already quite complicated.  This would seem to add a
>> huge amount of effort at compiler and at rntime.
>
> Why? From my naive point of view, that would be a simple comparison
> when saving. As for double registering -- I suppose that if
> registration data is kept in some std::map, then there are problems
> at all.

I have to confess I don't really understand the above.  Maybe it just sounds
complicated.

>
>> It would also add dead code to
>> almos t every executable using the library.
>
> IMO, this is clearly better than instantiate all of serialization
> library once for each archive type.

Note that serialization is instantiated only for archive whose headers are
included.

>
>> It would seem a huge price to
>> pay just to permit one to say.
>>
>> #include <boost/serialization/export.hpp
>> #include <boost/archive/text_iarchive.hpp>
>>
>> rather than
>>
>> #include <boost/archive/text_iarchive.hpp>
>> #include <boost/serialization/export.hpp
>
> No, there's a different concern -- the current approach does not
> scale. Say I have my_class.hpp and my_class.cpp. Somewhere in those
> files I have BOOST_CLASS_EXPORT, which instantiates serialization
> code for a number of archive types. Now I write a new archive type,
> in my_cool_archive.cpp. Suddenly, serialization of MyClass does not
> work. Now I need to add another include to my_class.cpp and too all
> other files that have BOOST_CLASS_EXPORT in it. That's no good.

>
> Now consider that a class is defined in a plugin. IIRC, that was one
> of the motivating examples for BOOST_CLASS_EXPORT. The situation
> becomes worse -- if a plugin is built with N archive types, and is
> packaged in binary form, but application defines it's own archive
> type, then serializing a class from plugin using that new archive
> type is not possible.

>
> 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.

Robert Ramey