Re: [boost] BOOST_CLASS_EXPORT (Was: serialization queston)

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-19 10:47:15

Vladimir Prus wrote:
> Robert Ramey wrote:
>
>> Upon (re) reading this, I'm not really sure what is being suggested
>> here. That's why I didn't respond to the original post.  I think my
>> view that there is no problem probably reflects my lack of
>> understanding of the original question.  Anyway - here it is.
>>
>> Robert Ramey
>>
>>> 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.
>>
>> I am generally not in favor of adding code not requested by the
>> library user and not required. I much prefer that the library
>> reflect what the user has said he wants. So my view is there are a
>> couple of options.
>>
>> a) if one want's to use a polymorphic archive, include that in a
>> (possibly precompiled) module.
>
> What I'm suggesting is that if no export code is registered for
> current arhive/class combination, the libraries tries
> polymorphic_archive/class combination.
>
> That at least assume that if I create a library the registers class
> with the polymorphic_archive, it will always work, even if client
> application does
> not explicitly use polymorphic_archive

In order for the polymorphic_archive to work, the client application MUST 
use a polymorphic implementation.  E.G. polymorphic_text_iarchive. Only the 
polymorphic implementations can link to the polymorphic_?archive headers and 
use the corresponding code.  So if one want's to be sure that things will 
"always" work there is only one method that I can see.

a) use polymorphic_?archive in pimple like headers for all classes.
b) insist that all users use polymorphic_????_?archive headers.

This will work even if newer polymorphic_????_?archive types are created and 
used.

>> b) if one want's to use the template archive implementations,
>> specify the ones you want.
>
> Let me ask a simple question: if I do
>
>   #include <boost/archive/text_iarchive.hpp>
>   #include <boost/archive/binary_iarchive.hpp>
>   BOOST_CLASS_EXPORT(MyClass);
>
> what's exactly get instantiated for two archive types?

You'll get code generated for each type of archive.

> If that's pretty much all of serialization library, then it's very
> much of a code bloat.

So it is.

> Now, if BOOST_CLASS_EXPORT registers with
> polymorphic archive
> by default, I can omit the #includes, and I'll get instantiations
> only for one type, plus some small forwarding function in polymorphic
> archive. The price is a small performance reduction but:
>  - it's very small compared to iostreams overhead
>  - it's not clear if there will be any -- smaller code size might even
>    increase performance due to less cache misses.

For those that hold this view, the polymorphic_?archive was invented so the 
above becomes:

>   #include <boost/archive/polymorphic_iarchive.hpp>
>   BOOST_CLASS_EXPORT(MyClass);

and it achieves exactly the benefits you describe above.  This no surprise 
as it was invented for just this purpose.  On the other hand, there are 
users which strongly argue that compile time instantiation can/will lead to 
faster code and code bloat is not a problem in their context.  In theory, 
this should be true.  But only recently have some people started to 
investigate whether it is in fact true with today's compilers.

>> c) if this generates too much code bloat, make a library which
>> includes any or all of the above. Its fairly easy to do this. Then
>> link against your library of serialization implementations. Only
>> ones actually used will be included in your program.
>
> You're making some assumptions that are true only for certain types of
> libraries built on certain platform with certain compiler.

Hmm - I suppose I am.  For what compilers/platforms/libraries would the 
above not be true?

Robert Ramey