Re: [Boost-users] [Boost][serialization] Serialization and DLLs

From: Topi Mäenpää (topi.maenpaa_at_[hidden])
Date: 2005-11-07 07:44:40

> I have a suggestion, please comment. The problem _could_ be in that
>> guid_initializer isn't exported. If I register my base class in a 
>> DLL, the DLL interface does not expose the 
>> guid_initializer::instance I have created. Since my exe now doesn't
>>  know about it, it creates a new definition. The same applies to 
>> other DLLs. (This would also explain why the same code works on 
>> Linux: all symbols are automatically exported.) What if we exposed 
>> the guid_initializer struct to the DLL interface? Would it help? At
>>  least it shouldn't do any harm to export it from the exe.

> That might explain the behavior.  We'll look into it.  I'm having
> problems making test which uses a dynamically loaded DLL that I can
> run under bjam.

No, it didn't work... I also exported the extended_type_info subclasses 
(_0 and _1) from my DLL, but I still encounter the same problems.

The code lacks comments, and I find it difficult to study some some of 
the constructs. It seems that whenever I register a class, its 
superclasses get registered as well. The extended_type_info pointer for 
my common superclase is however different for each instantiation. The 
exe crashes due to an unhandled unregistered_cast exception thrown at 
oserializer.hpp:408. Thus, it seems that downcasting cannot succeed. I 
even modified the extended_type_info so that it always compares keys 
literally instead of pointers, but this has no effect. Furthermore, I 
changed the tkmap and ktmap multisets to sets. I assumed this could 
prevent multiple registrations, but it does not.

Could someone point me out a way to work around this? Any temporary 
solution will do until the problem has been identified and fixed.

Best regards,
Topi