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

Subject: Re: [Boost-users] [serialization] Export question
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-04-09 00:10:49

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?

-t