Emil Dotchevski wrote:
Emil Dotchevski wrote:
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.
I see BOOST_CLASS_EXPORT a little differently. The main function is to assign an externalizable string to the class to permit reference to it outside of any execution context. Currently part of the serialization library implementation is mixed into this. In hindsight I would have separated out things better. And maybe it will happen someday. But the macro itself is pretty opaque and its function beyond assigning an external name isn't convenienttly available to users. So from a user's point it assigns this name attribute to a class. So to me it seems natural to included in the header along with the whole class declaration. That way when that header gets used by other programs, they all share the same external name - as they should since they're sharing the same header. Of course when you change the external name of something, you're going to have problems connected with users of the old name - in this case existing archives. But, as you pointed out, that is a different problem. Robert Ramey