From: Martin Reinecke (martin_at_[hidden])
Date: 2001-07-18 16:38:42
On Wed, Jul 18, 2001 at 02:02:05PM -0500, Bill Seymour wrote:
> I have a couple of problems with this.
> First, why throw exceptions for conditions that might not be
> errors? For example, when a user asks to load a DLL that's
> already loaded, why not just do nothing at all?
That's true; I think this exception should be removed.
However, the same is not true for CLASS_ALREADY_LOADED, since two
classes with identical names might be defined in different DLLs.
But I suppose in this case we would be in trouble anyway (I guess
it would be analogous to a violation of the ODR).
> Note that
> this has implications for MAKER_BASE::~MAKER_BASE(), which
> can throw an exception.
Right. If DLC is implemented correctly, this exception cannot be thrown
at all, and can safely be removed. It's in there mostly as a sanity check
I should note that the current implementation is not much more as a proof
of concept, and that many things have to be polished before DLC can be
used seriously. To find out what has to be done and if it is worth the
effort is the main reason why I wrote to this mailing list :)
> Second, there's some magic surrounding the DLC_Register_Macro
> macro that I'm not seeing. The macro seems to generate text
> that looks curiously like a function prototype, but has an
> actual argument instead of a formal argument. What am I
The macro expands not a prototype but to the definition of a static global
When the DLL is opened, the constructor of this object is executed; the code
in the constructor registers the class in question with the global DLC::Server.
When unoading the DLL, the destructor of this object removes this registration
I use a macro here because the object definition contains some redundancy
(the name of the dynamically loaded class appears more than once).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk