From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-03-19 17:16:25
> Dave Harris said: (by the date of Mon, 19 Mar 2007 19:21 +0000 (GMT))
>> In other words, if you support BOOST_CLASS_EXPORT() then you
>> should also support BOOST_CLASS_EXPORT_ALIAS().
>> If by this you mean they should convert all the user data in one huge
>> conversion binge, then that's not always practical. Sometimes the
>> conversion has to be done inline, with the old archive format supported
>> forever by all future version of the program.
> I agree 100%, because code refactoring is a very important aspect of
> software design. Even in the advanced stage, when the software is
> released and in production. Keeping backward compatibility _and_
> being able to make code refactoring is a very big advantage.
This is how I personally read the above statement: persistent identifiers
used by a serialization library should be decoupled from C++ type names to
limit invalidating file formats due to refactoring.
I agree with Robert that supporting BOOST_CLASS_EXPORT_ALIAS is outside the
scope of Boost Serialization.
In my opinion, all you have to do to avoid having this problem is not use
BOOST_CLASS_EXPORT in your header files, and instead register your classes
manually. Technically speaking, BOOST_CLASS_EXPORT is guaranteed to work
only if it's used in a compilation unit that is called explicitly: you can't
rely on BOOST_CLASS_EXPORT to link the necessary serialization code just
because you link a CPP file that uses BOOST_CLASS_EXPORT. Therefore the only
thing automatic about this macro is that it uses the class name as
persistent identifier of the class (which is the source of the problem at
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk