-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Thursday, June 15, 2006 10:28 PM To: boost-users@lists.boost.org Subject: Re: [Boost- users]boost::serializationunregistered_classexceptionswith DLL.
Roman Neuhauser wrote:
# ramey@rrsd.com / 2006-06-15 10:30:49 -0700:
The global table might include a handle to the code module which created the entry. This could be used to be sure that the correct entry is deleted as teh DLL is deleted. In windows there is a call to retrieve a handle to the current module - main, DLL etc. I don't know what the corresponding call is on a unix/cygwin/ etc environment. Any one is free to chime in here.
How about just reference counting the types?
Not enough. DLLS can be unloaded in different order than they are loaded.
What is needed is to include a handle of the module doing the registration. I can find the magic handle in windows - but I don't know how to do it in UNIX.
Robert Ramey
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