|
Boost Users : |
From: Topi Mäenpää (topi.maenpaa_at_[hidden])
Date: 2005-11-04 07:07:18
> 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.
-Topi-
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