Re: [Boost-users] [serialization] Export question

Subject: Re: [Boost-users] [serialization] Export question
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-04-09 02:33:34

troy d. straszheim wrote:
> Robert Ramey wrote:
>> BOOST_CLASS_VERSION should be in the header.  This might be
>> overkill, but its a natural place for it, it's bonehead proof and
>> doesn't have any side effects.  BOOST_CLASS_EXPORT has the side
>> effect of instantiatine code so it's "special"
>>
>> My original intention was that all these "serialization traits" be
>> part of the class header description.  BOOST_CLASS_EXPORT sort of
>> broke this idea but it still holds for the other ones.
>>
>
> Right, the version macro just creates a version trait
> specialization-majig.  Here's our case... maybe there's no good
> solution, if so, no big deal.  To keep compile times down we try to
> keep all the serialization stuff out of our headers except for the
> (dependencyless, happily) declaration of the serialize function
>
> struct C : Base {
>
>   template <class Archive>
>   void
>   serialize(Archive&, const unsigned);
>
> };
>
> and we instantiate the serialize function for several different
> archive types in the .cpp, via macro
>
>   #include <all_the_heavy_serialization_headers>
>
>   template <class Archive>
>   void C::serialize(Archive& ar, const unsigned version) { ... }
>
>   SERIALIZABLE(C) // instantiates and exports
>
> I've mentioned this before.  Nearly all of these hundred-or-so classes
> are serialized in one place via pointer-to-base.   So it'd be nice to
> have the headers completely clean of serialization #includes.  If not,
> no big deal, but:
>
> I don't really get why, if the library that does the serialization
> for C can't see C's header (it goes via shared_ptr<Base>, and has
> loaded C's code from a shared library),  does the BOOST_CLASS_VERSION
> need to be in the header?  Shouldn't the version-checking business
> get taken care of at the point of instantiation of the serialization
> method for C?

Sounds correct to me. Truth is, I envisioned that the serialization 
attributes
are attributes of the class so it was natural to to make them part of the 
header.
The main concern would be when one used inline code (since serialize 
function
is often very simple.  If these macros weren't in the header you might endup
doing it one way in one program and differently in annother.

Note that you don't have to include ALL the headers.  You only have to
include the headers corresponding to the macros you're using.

So it seems your correct - the real rule would be that the specializations
have to be visible when the code is instantiated.  It's a more complicated
rule, but in the case you describe, it might be worth it.

Robert Ramey

>
> -t