From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-03-16 14:30:04
> This was my thought as well. In fact, I'm going to switch all our
> BOOST_CLASS_EXPORT(T) macros to BOOST_CLASS_EXPORT_GUID(T, "[T's
> canonical name]") macros, and leave a giant note for others to do the
> same ("Here there be dragons", etc.). In light of this problem, I
> would say that while use of BOOST_CLASS_EXPORT() is convenient, it is
> ultimately a maintenance burden.
In my opinion the convenience of BOOST_CLASS_EXPORT is offset by the problem
Zach is facing, as well as by the physical coupling it introduces between
user classes and boost::serialization.
Because serialize/load/save are function templates, and because all
serialize/load/save calls made from inside another serialize/load/save
function template depend on a template parameter (the Archive type), in
principle the serialization of a given class foo can be defined in foo.hpp
without including any boost serialization headers, however this is not
possible if BOOST_CLASS_EXPORT is used, because its purpose is to trigger
the registration automatically just because foo.hpp is #included.
I would suggest separating all registration in a single compilation unit
called explicitly by the main initialization code (having everything in one
place makes it much easier to keep track of the IDs for each class.) That
compilation unit would include the headers of all classes that need to be
serialized, as well as the registration facilities of boost serialization,
and register each combination of class and archive that the program uses
(each dynamically linked library would need its own similar initialization
as well.)
Emil Dotchevski