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