Boost logo

Boost Users :

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-11-03 11:50:55


Topi Mäenpää wrote:
> Hi,
>
> Some time ago, we had a discussion about serialization of dynamically
> loaded classes. I got my code work on Linux, but still cannot do the
> same on Windows. I'd like someone to elaborate the stuff below a bit:
>
> Robert Ramey wrote:
>> Another post has me convinced that the problem is that there are
>> multiple copies of a base class extended_type_info record which I
>> believe shouldn't occur.
>
> I can confirm that this indeed happens.
>
>> If you trap your debugger the serialization.dll (shared_lib) at line
>> 58 of extened_type_info.cpp you should trap every time an
>> extended_type_info record is "self_registered". Examination of the
>> stack should reveal
>> where this is being called from. I expect that the base class is
>> being self registered from both the DLL as well as the main
>> executable.
>
> Whenever I register a class from a DLL, its base classes get
> registered as well, although they already have been registered. If I
> load multiple DLLs that all contain derived classes, the base classes
> are registered many times, but only once for each DLL.

This surprises me and it never occurred to me that this would happen.
Clearly, this is uncharted territory.

>> My current thinking is that this behavior should be prohibited and
>> detected with an exception. Other users have addressed this
>> by tweaking the code in extended_type_info.cpp to permit
>> multiple "self registration" of the same extended_type_info type.
>> This eliminated their symptoms and everything seems to work.
>> But from my understanding of the library, I believe this just
>> hides a deeper problem.

> Can someone point out the details? How should this be done? Any other
> suggestions?

One really needs a test case to test this one thing. I've started to make
one
but its gotten hung up on some details in getting worked into my Jamfile so
I set it aside. I'm convinced that the above - prohibiting and trapping
this
behavior is the correct way to go. However, to make this work, base classes
need to be registered only once. This would take some looking into.

So the problem is already ratched up to another level of complexity.

class X can be in a DLL.
class Y can be in an application

everything is fine so far

class Z :: public class Y creates a problem in that class Y gets registered
in the application even
if its already in the DLL. This will require some thought to know what the
correct way to
handle this is.

Robert Ramey


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net