Re: [Boost-users] boost::serializationunregistered_classexceptionswith DLL.

From: Terence Wilson (tez_at_[hidden])
Date: 2006-06-19 17:22:58

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of Robert Ramey
> Sent: Thursday, June 15, 2006 10:28 PM
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-
> users]boost::serializationunregistered_classexceptionswith DLL.
> 
> Roman Neuhauser wrote:
> > # ramey_at_[hidden] / 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