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 without 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 you don't use BOOST_CLASS_EXPORT. See http://www.archivesat.com/Boost_developers/thread2900871.htm.
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 BOOST_CLASS_EXPORT.
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 BOOST_CLASS_EXPORT.
If you're about to serialize derived classes via pointers to base classes, BOOST_CLASS_EXPORT is pretty much a must.
BOOST_CLASS_EXPORT is designed to make the necessary registrations automatic, but in doing so it introduces physical coupling that is undesirable for anyone who includes a particular class' header but does not need to serialize objects of that class. I also think that having BOOST_CLASS_EXPORT deduce the persistent class name automatically inhibits maintainability, as any refactoring that changes class names would break all serialized data. I prefer having one place in my program where I register all classes with their persistent names, so I can make separate decisions when to rename classes and when to change persistent names. Emil Dotchevski