On Wed, Sep 24, 2008 at 9:43 PM, Robert Ramey <ramey@rrsd.com> wrote:
Note that we've had lots of difficulties with export. This is due to the fact that it relies on indicating to the compiler that something shouldn't be stripped. The way of doing this is compiler dependent - see
We've discussed this before -- not only it is compiler-dependent but a conforming compiler may not provide a way for this deadstripping to be disabled. Plus, isn't it somewhat disturbing that to use BOOST_CLASS_EXPORT we need to tell the compiler NOT to optimize aggressively? :) There is another problem as well: it is useful to be able to have a function which registers classes to be serialized, then serializes them, then frees all the memory taken by the registration (this is a separate issue, but being able to unregister also allows unloading of dynamic libraries.) So why not allocate the object that stores the registration state dynamically? For example, provide a factory function: shared_ptr<serialization_class_registry> create_serialization_class_registry(). Of course, the user is free to store the returned shared_ptr globally if that suits their taste. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode