By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,967 Members | 1,576 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,967 IT Pros & Developers. It's quick & easy.

Shared Library Question

P: n/a
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.
Jul 19 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
"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
Jul 19 '05 #2

P: n/a
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 !!


Jul 19 '05 #3

P: n/a
"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/
Jul 19 '05 #4

P: n/a
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

Jul 19 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.