Shared Library Question

[listigerBiber]

Hello,

i want to extend a program of mine with a plugin architecture.
I can load and use the shared libs which are implementations of a
abstract base class without any problems. But what i need is a
bi-directional interface, the plugins have to acess objects of the
main programm (pointers to them are passed at plugin initialisation).
This works too - but only if i include the header and .cpp files of
these api objects into every plugin - and that is bloated bullshit !

is there a way to include the api .h files only and uses the
implementation code from the main-application (gcc 3.2 linux 2.4) ??
if i try to do that library loading fails with unresolved symbols
.....

Thanx C.S.

[Victor Bazarov]

"listigerBiber" <c.********@urz.uni-heidelberg.de> wrote...

i want to extend a program of mine with a plugin architecture.
I can load and use the shared libs which are implementations of a
abstract base class without any problems. But what i need is a
bi-directional interface, the plugins have to acess objects of the
main programm (pointers to them are passed at plugin initialisation).
This works too - but only if i include the header and .cpp files of
these api objects into every plugin - and that is bloated bullshit !

is there a way to include the api .h files only and uses the
implementation code from the main-application (gcc 3.2 linux 2.4) ??
if i try to do that library loading fails with unresolved symbols
....

What you need is to provide an SDK to the writers of plug-ins. You
have determined what classes plug-ins need, now you have to expose
those classes. The most convenient way is to create "pure abstract"
interfaces. The real objects that will do the work you will create
on demand in some kind of factory function. The plug-ins will call
your factory or will receive the pointers to base classes some other
way, then will call the methods of those base classes, which will
resolve in calls to the implementations through polymorphism.

So, you basically on the right track. Simply extract the interface
the plug-ins will use into the base class, declare those functions
virtual and pure. Make your classes derive from those interfaces,
create the instances of your classes and pass the addresses as base
class pointers to plug-ins.

Victor

[Allen]

Hi listigerBiber, all,

One way to implement a C interface which I have used quite a lot is to make each plugin have only one function. The function returns a pointer to a C
struct which has nothing but function pointers.

id's QuakeII engine (GPL) uses a very similar method. The loading
module and loaded module exchange references through one function call.

struct import
{
//lots of pointers to funcs in other module
} Ii;

struct export
{
//lots more pointers to funcs in current module
}Ie;

//init pointers in Ie to local functions you want to access in other module

__declspec(dllexport) import GetAPI(export Ie); //defined in other
module--platform specific interface
Ii = GetAPI(Ie); //this func saves off the Ie info and then inits the Ii
pointers to its local funcs to be accessed in the calling module
I have a different method for doing the same thing. I made a global
data tree where each node looks like:

struct Glob
{
char szName[MAX_STRING];
DWORD dwFlags; //valid fields and requests
char szValue[MAX_STRING];
int iValue;
float fValue;
void* pVoid;
PGLOB pParentGlob;
PGLOB pLeftGlob;
PGLOB pRightGlob;
};

Then, pointers to my equivalent of the above import/export structs would
be placed in Glob::pVoid for all to access.

HTH
--

Best wishes,
Allen

No SPAM in my email !!

[Cy Edmunds]

"Allen" <al************@att.SPAM.net> wrote in message
news:WM*********************@bgtnsc04-news.ops.worldnet.att.net...

Hi listigerBiber, all,

One way to implement a C interface which I have used quite a lot is to make

each plugin have only one function. The function returns a pointer to a C struct which has nothing but function pointers.

id's QuakeII engine (GPL) uses a very similar method. The loading
module and loaded module exchange references through one function call.

struct import
{
//lots of pointers to funcs in other module
} Ii;

struct export
{
//lots more pointers to funcs in current module
}Ie;

//init pointers in Ie to local functions you want to access in other

module
__declspec(dllexport) import GetAPI(export Ie); //defined in other
module--platform specific interface
Ii = GetAPI(Ie); //this func saves off the Ie info and then inits the Ii pointers to its local funcs to be accessed in the calling module
I have a different method for doing the same thing. I made a global
data tree where each node looks like:

struct Glob
{
char szName[MAX_STRING];
DWORD dwFlags; //valid fields and requests
char szValue[MAX_STRING];
int iValue;
float fValue;
void* pVoid;
PGLOB pParentGlob;
PGLOB pLeftGlob;
PGLOB pRightGlob;
};

Then, pointers to my equivalent of the above import/export structs would be placed in Glob::pVoid for all to access.

HTH
--

Best wishes,
Allen

No SPAM in my email !!

Funny you should mention QuakeII. I'm the author of the QuakeII mods WoD7
and WoD8. :) But as you say, it was iD software that wrote the stuff you're
talking about.

Guess in this context I'll use my real sig, including my QuakeII clan name
LOL

--
Cycho{HHR}
http://home.rochester.rr.com/cyhome/

[listigerBiber]

Thank you very much !
your hint with the abstract base class for the pluginfactory worked
....
of course the pluginfactory or application api must have a pure
virtual base class !!

"Victor Bazarov" <v.********@attAbi.com> wrote in message news:<9l*******************@rwcrnsc51.ops.asp.att. net>...

"listigerBiber" <c.********@urz.uni-heidelberg.de> wrote...

i want to extend a program of mine with a plugin architecture.
I can load and use the shared libs which are implementations of a
abstract base class without any problems. But what i need is a
bi-directional interface, the plugins have to acess objects of the
main programm (pointers to them are passed at plugin initialisation).
This works too - but only if i include the header and .cpp files of
these api objects into every plugin - and that is bloated bullshit !

is there a way to include the api .h files only and uses the
implementation code from the main-application (gcc 3.2 linux 2.4) ??
if i try to do that library loading fails with unresolved symbols
....

What you need is to provide an SDK to the writers of plug-ins. You
have determined what classes plug-ins need, now you have to expose
those classes. The most convenient way is to create "pure abstract"
interfaces. The real objects that will do the work you will create
on demand in some kind of factory function. The plug-ins will call
your factory or will receive the pointers to base classes some other
way, then will call the methods of those base classes, which will
resolve in calls to the implementations through polymorphism.

So, you basically on the right track. Simply extract the interface
the plug-ins will use into the base class, declare those functions
virtual and pure. Make your classes derive from those interfaces,
create the instances of your classes and pass the addresses as base
class pointers to plug-ins.

Victor