Boost logo

Boost Users :

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-11-04 10:54:04


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

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