I believe it is fixable in a general and definitive way. And I've slowly been gathering the information needed to address this for differenent operating systems. Also, I havn't been able to see a way to use bjam to run a test which dynamically loads/unloads separately built DLLS. I'm still thinking about this. Also, I don't have the time I used to for this stuff, so - short answer is that I wouldn't count on this being addressed anytime soon. Note that this isn't really a design feature of the library. Its just that the concept what DLLS which contain partial class implementations (with base impleentation somewhere else) was never considered. We tried to consider everything - but its not easy Robert Ramey Terence Wilson wrote:
-----Original Message----- Robert,
I've used your serialization library for small projects and I like it a lot, however, the DLL class registration bug/oversight makes it all but impossible to use in a Windows project that separates implementation of classes across modules. We have several classes that have encapsulated bases implemented within a 'base' DLL, specializations of these classes are loaded at runtime on an as-needed basis. Your current design requires that *all* class registration occur within the base class module, in other words, the base DLL must have knowledge of all other DLL classes that derive from one or more of its base classes. This turns any good object-oriented design on its head and is not an option.
Is there any chance of a fix in the near future?
Thanks,
Terence