From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-05-04 15:16:19
Emil Dotchevski wrote:
>> Emil Dotchevski wrote:
>>> If X is usable without serialization, users shouldn't be forced to also
>>>> link to the serialization library, just because of this dependency.
>>>> (In the particular case I have in mind this dependency was controlled
>>>> by a preprocessor macro. That's not very practical, since packagers
>>>> surely won't provide two sets of packages for X, one with and one
>>>> this dependency.)
>>>> Thus, I'd suggest to encapsulate the X-serialization functionality into
>>>> a separate library (may be header-only), such as X_serialization.hpp
>>>> etc. Then I can still use X stand-alone, and drag in the rest whenever
>>>> I need it.
>>> This has been discussed before. You don't need X_serialization.hpp, if
>>> don't use BOOST_CLASS_EXPORT. See
>> I'm not sure how relevant that is. If X.hpp contains
>> serialization-related code, it surely needs to include serialization
>> header files, too, to drag in any relevant declarations. Thus there is a
>> dependency from X to serialization.
> You need no declarations because the serialization is implemented as a
> function template:
> class foo;
> template<class Archive>
> void serialize(Archive & ar, foo & x, const unsigned int version)
> ar & x.bar;
> The above code compiles without including any boost serialization headers.
> I have not used boost serialization (I have my own serialization library),
> but as far as I can see the reason why foo.hpp that uses boost
> serailization needs to include serialization headers, is to be able to use
If you serialize classes with base classes, you need to include
base_object.hpp, and if you want your serialization to be
compatible with XML archives, you have to include nvp.hpp,
so it's not possible to completely avoid including serialization headers.
> For me this is good enough reason not to use
If you're about to serialize derived classes via
pointers to base classes, BOOST_CLASS_EXPORT is pretty much a must.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk