Re: [boost] [serialization] Support for multiple class name strings

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-03-16 21:08:03

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