"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:
Felipe Magno de Almeida wrote:
Is more than one BOOST_CLASS_EXPORT, in different
translation files, suppose to work?
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.
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.
The extended_type_info.cpp file uses a std::multiset<const extended_type_info *, ...> and remove_key tries to handle duplicate insertions in ktmap. But it fails always to do that, because m_key will be set to zero and so ktmap will be in a corrupted state since its key_compare asserts on m_key == 0.
This may be an error. I haven't looked it it yet. Robert Ramey