Re: extern "C" and wrapping

From:

James Kanze <james.kanze@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Thu, 05 Jul 2007 08:08:57 -0700

Message-ID:

<1183648137.202490.239710@w5g2000hsg.googlegroups.com>

On Jul 5, 1:01 pm, "b...@blah.com" <GrahamJWa...@gmail.com> wrote:

we're faced with a horrible scenario whereby we are not able to access
exported classes in a DLL due to cross compiler issues.

Traditional approaches such as using extern "C" and LoadLibrary
(nothing to do with C++ I know but I'll get to my question... :).
Anyways, we need to access our exported objects and the only safe
route I know to get to the destination dll/lib from our client (not in
same environment) is by using extern "C" for various functions.

However doing this I lose all my object orientation. Is there any
pattern/approach out there available that will allow me to use extern
"C" such that its implementation gives me access to the C++ objects
implemented in the target DLL/LIB. I think this must be an age old
problem I'm just stumped by it and I honestly think somebody has a
clever pattern/approach to this that will allow me to bypass the
problem at hand.

I obviously can't replace all my objects method calls into extern "C"
functions and in paralell this must scale. I.E as new functions/
classes are added , I need to be able to access them without too much
pain, extra work.

Does anybody know of such a solution? Or is this unsolveable...i.e.
I'm asking too much.

The way I usually handle plugins and such is to declare a
single, extern "C" function which returns a pointer to the
abstract base of a factory class; I then call member functions
on the factory class to get the objects I want (or do anything
else in the plugin, for that matter).

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34