On Mon, Mar 31, 2008 at 6:35 PM, Robert Ramey <ramey@rrsd.com> wrote:
"Felipe Magno de Almeida" <felipe.m.almeida@gmail.com> wrote in message news:a2b17b60803311200v75904141rbe56c2713ef6fe7d@mail.gmail.com...
On Mon, Mar 31, 2008 at 1:00 PM, Robert Ramey <ramey@rrsd.com> wrote:
[snip]
I never considered the possibility that this would ever occur. I see no reason to ever do this and no reason why it should be difficult to avoid doing. I would say is a user error.
What if someone wants to create serialization code for multiple archives in different translation files? I know this is not *very* compelling, but it is a honest use for multiple BOOST_CLASS_EXPORT.
I would like to see BOOST_CLASS_EXPORT in the *.cpp file which contains the class definitions. There should only be one of those. Look at it this way - multiple definitions of the same function will give an error at link time - but here - link time is moved to runtime.
What if this happens: -- src1.cpp #include "type.hpp" // serialization type #include <boost/archive/xml_iarchive.hpp> BOOST_CLASS_EXPORT(type); // instantiates serialization for iarchive.hpp -- src2.cpp #include "type.hpp" #include <boost/archive/xml_oarchive.hpp> BOOST_CLASS_EXPORT(type); // instantiates serialization for oarchive.hpp -- Why should this code be considered an error?
I would like to trap it as such, but there is no way to distinguish it from the legitimate case where the some type is exported from multiple DLLS.
Changing std::multiset to std::set would be enough, wouldn't it?
Nope - that was exactly the problem. If the same type is used in different DLLS, then there will be multiple static objects created each loaded/unloaded as the dlls themselves are loaded/unloaded.
But they will have different addresses won't they? The problem is with the same instance added twice to ktmap. Changing to std::set will allow the same type to be added, but not the same instance. Also, I would like to suggest changing ktmap and tkmap to a more descriptive name. I know it is an implementation detail, but it is very easy to get confused when debugging this.
Robert Ramey
-- Felipe Magno de Almeida