Re: [boost] [serialization][1.36]ktmapcontainsextended_type_infowithm_key == 0

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-03-31 17:35:31

"Felipe Magno de Almeida" <felipe.m.almeida_at_[hidden]> wrote in message 
news:a2b17b60803311200v75904141rbe56c2713ef6fe7d_at_mail.gmail.com...
> On Mon, Mar 31, 2008 at 1:00 PM, Robert Ramey <ramey_at_[hidden]> 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