[boost] BOOST_CLASS_EXPORT (Was: serialization queston)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-19 01:41:02

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

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

If that's pretty much all of serialization library, then it's very much of a
code bloat. 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.

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

- Volodya