On loading classes from a DLL...

I'm assuming if you want to use a different class at runtime depending on 
something a user types in (for example), what you need to do is...

1) Declare class Alpha with a bunch of virtual functions to do what you want 
in the main program.

2) Declare class Beta that inherits from Alpha in the DLL, implementing 
those virtual functions appropriately.

3) Declare a global function that returns pointers/references to instances 
of Beta in the DLL.

[repeat 2 and 3 for each class you might want to use as a child of Alpha]

4) Declare some sort of forward reference to the global function in (3) that 
gets filled in by loading the DLL (i.e., the dynamic linking part).

At runtime, load the correct DLL based on what the user typed, then invoke 
the global function and assign the result to a reference/pointer to Alpha.

Is that how you'd do dynamic code loading in C++? Or is there a better way? 
In particular, I'm assuming any code that actually instantiates a Beta is 
going to have to be in the same DLL that defines Beta, and that the main 
program can't actually refer to Beta if the main program gets compiled 
before the DLL gets written?

I'm thinking things like (say) editor macros, or "plug ins", or "stored 
procedures", or something like that, where you'd want to be able to load 
code at runtime that was written after the main routine was compiled.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

http://en.wikipedia.org/wiki/Dynamic-link_library has a brief explanation
of how DLLs work and are used.

  AFAIK what you wrote is how it would work. The DLL defines a function
which returns eg. a pointer of base class type (which is known by the
program). The actual object returned by the function can be anything
derived from that base class, without the program needing to know what
it is.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   AFAIK what you wrote is how it would work. 

Cool. Yeah, I know how shared libraries work with C. I just wasn't sure 
whether the subclassing mechanisms would work across dynamic load boundaries 
in C++. Good to know. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:
> http://en.wikipedia.org/wiki/Dynamic-link_library has a brief explanation
> of how DLLs work and are used.

Heh.

"""
DLLs create non-obvious links between a program and code fragment 
"somewhere" in the system: even simple programs may not be totally contained 
in its .exe file, but be spread out over, and be dependent on, multiple 
DLLs. The exact location and depth of those dependencies may be difficult or 
impossible to determine. Since DLLs can call other DLLs, the chain of 
complexity can extend to any depth.
"""

The funny thing is, you could say the same thing about applications. It's 
interesting that Singularity is actually addressing this, where applications 
have to say what other applications they talk to, that installing or 
removing an application has to leave the system in a consistent state (as 
in, you can't install an application X that talks to server Y unless server 
Y is installed too). They took the idea of "application" and made it a 
first-class value that you can inspect the properties of, instead of it 
being a pile of files somewhere that contain code. It'll be interesting if 
Singularity ever escapes the labs.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message