[Boost-users] Re: Guide to using serialization macro BOOST_CLASS_EXPORT

Bill Lear wrote:

I am having some trouble understanding just where I am supposed to put BOOST_CLASS_EXPORT macros for classes I write --- in class headers (.h), in class implementation files (.cc), in applications that plan to save/load through base pointers?

The whole concept behind BOOST_CLASS_EXPORT has been problematic for me for a couple of reasons. As a result, the confusion you cite is a real one. My intention was that: a) BOOST_CLASS_EXPORT be part of the header file for a particular class. b) A typical program would look like: #include // other archives used. #inlcude "my_class.hpp" // other classes from my library. many of which will use EXPORT main(){ ... // the BOOST_CLASS_EXPORT will guarentee that code required for serialization for derived classes is // included in the program even though it is not explicitly referred to by name. Without // BOOST_CLASS_EXPORT, a smart compiler/linker will conclude this code is never called // and throw it away on linking. ... } c) BOOST_CLASS_EXPORT emits code for each archive template for the class specified. This could contribute to code bloat d) This system requires that the #include for archives preceed those for serialization implemenations. A violation of this requirement should result in a compile time failure with and error message and point to code with a comment explaining the problem. I've toyed with re-implementing this to get around problems created by two-phase lookup but managed to address these in another way so I don't expect this explanation to change in the near future.

I have base class B, from which I derive lots of classes. I tried putting the BOOST_CLASS_EXPORT in the header files of each class, but soon found that this resulted in link-time errors due to multiple definitions.

I'll look into this. It might be fixable. It was my intention to permit this. Note that including BOOST_CLASS_EXPORT to programs which don't in fact serialize through a base class pointer may instanciate code that is in fact never called. I'll look into this as well. Robert Ramey