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

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-11-07 23:53:06

Topi Mäenpää wrote:
>> 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.

I'm not sure what code we are refering to but in any case I believe
you are using VC 7.1 as am I.  In this case it should be easy to
run the code under the debugger an trap the registration to see
where its getting called from.

> 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.

Note that the current version checked into the next release branch has
this change.  It seems that we're  not using the same code.

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

You might benefit by downloading the latest - and hopefully soon to be
released version.  1.33.1 (RC_1_33_0).  we would have a better
basis for comparing.

Robert Ramey

>
> Best regards,
> Topi