Emil Dotchevski wrote:
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,
agreed.
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 don't think that's true. It was that code was only instantiated when an archive class header was also included. But this implied a header ordering requirement when some found difficult to live with. This was addressed in the HEAD so that there is no restriction on header order. My understanding was that this wouldn't change anything other than fixing the header ordering restriction.
I wasn't pointing at any implementation difficulties. All I am saying is that if I have class foo defined in foo.hpp, the use of BOOST_CLASS_EXPORT in foo.hpp is undesirable because it introduces physical coupling between the boost serialization library, class foo, and all code that's using class foo (even code that does not serialize objects of class foo), because such code would at least "see" the type registration facilities of boost serialization. I realize that this note is slightly off-topic to this thread, but I believe it is still relevant. I would rather use a system where the class IDs for all classes are specified "manually" in a single compilation unit where all registrations take place in a function called explicitly, when it makes sense to initialize the serialization system. This would have avoided some of the difficulties Zach experiences now. Emil Dotchevski