Re: [Boost-users] [serialization]conflicting declaration(BOOST_CLASS_EXPORT)

Subject: Re: [Boost-users] [serialization]conflicting declaration(BOOST_CLASS_EXPORT)
From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-09-25 01:29:49

On Wed, Sep 24, 2008 at 9:43 PM, Robert Ramey <ramey_at_[hidden]> 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