From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-03-16 17:47:15
> 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,
>> 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
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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk