Re: Dylib and parent application symbol access
Re: Dylib and parent application symbol access
- Subject: Re: Dylib and parent application symbol access
- From: Robert Bielik <email@hidden>
- Date: Tue, 10 Jan 2012 10:08:58 +0100
mark skrev 2012-01-10 10:03:
Exactly, how come you need to have it depend on the application ? The normal thing to do when designing plugin systems is to have a defined API which the APP knows about and the plugin implements, i.e. there should be no dependency towards the APP.
The parent APP has exported functions in the form of RegisterFunction, RegisterFilter, ... .
I found it easier for the lib to register what functionality it has this way as oppsed to the APP querying what functions it has.
Then you would do something like:
1. When initializing your plugin (or others), pass with it an instance of an API that has the RegisterFunction etc. methods.
2. In the initialize method of the plugin, the plugin "calls back" to that API which is implemented in the APP.
This way you still have no explicit dependency towards the APP.
Regards,
/Rob
Then the APP just loads whatever plugin it finds conforming to the API (this you'll need to define yourself what that means). You'd be using dlopen for this.
Check this thread on stackoverflow for some ideas: http://stackoverflow.com/questions/1516476/how-to-create-some-class-from-dllconstructor-in-dll
Regards,
/Rob
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
My mistake.
I believed you could actually do it (Waaaayyyy back in CW days you could use a stub library to fill in for it. I made the mistake you can do it now).
I assumed because an NSBundle could link to it's parent APP's exported functions/symbols, a dylib could.
Oh well. Thanks for the info.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden