Printable View
Hi,
I wrote a program that load some shared library I also wrote.
My problem is that the library implements an abstract class and the program has the the .h so it can use the library object. The thing is that I want it to be both ways.
I want to be able to give the library a object of the main program (as a pointer) and be able to use it from the library but I don't want to have de .cpp of that class at compile time when I compile the lib.
Can I do this? any ideas?
Thanks!
As long as the library has access to the appropriate header files, then yes, you can do this. Since you say "shared library" and not "DLL" I'll assume you mean UNIX. You need to link your main program using the --export-dynamic flag to the linker which will cause its global symbols to be made available for other dynamic code. So the shared library can use dlsym() to obtain function pointers from the main program.
If you are using gcc to link, you can pass "-Wl,--export-dynamic" (no spaces)
Thanks!
I'll try this out later.
Why do you want a library to be dependent on an application? Isn't that kind of backwards?
It's not uncommon, especially on Windows. It makes more sense if you think "shared object" instead of "shared library." Not every dynamic component need be thought of as a library. Consider an application plug-in. This plug-in probably needs to call the parent application in various ways. This could be done through a set of function pointers, but it could also be done directly if the applications exports dynamic symbols.Quote:
Originally Posted by medievalelks
Whether you provide component linkage through function pointers or direct calls, you still must maintain a compatible API between the components. So as far as code architecture there is no strong argument either way.
For whatever reasons (probably philosophy), the "application-as-collection-of-dynamic-components" concept is uncommon on UNIX systems, but the support for it is there.
The idea is exactly for a plugin.
But if there's any better way of doing this please tell me. I don't really know much about plugins and such.
You could use --export-dynamic, but you need to think carefully about what you allow the plug-ins to call. By exporting your application's symbols, you allow the plug-in to call any function in the application that it wants. That's dangerous, because somebody may develop a plug-in which becomes wildly popular that uses some function inside your application that you want to eliminate. Now you can't, because this popular plug-in requires it.Quote:
Originally Posted by p1r0
You might want to consider some kind of class which proxies for the application and exposes only a limited set of functionality. When the application initializes the plug-in, it can pass an instance of this class, and the plug-in will interact with the application only through this class.
This is what I wanted to do, bunt couldn't find out how to without providing the implemantation for that class to the plugin ant compile time, and that is something I don't wanna do either.Quote:
Originally Posted by brewbuck
I had and abstract class for this, but could not use objects of that type as arguments for the method of the plug in that would get an instance of the proxy.
Why not? You can pass abstract pointers/references and still use the underlying object.Quote:
Originally Posted by p1r0
I'm really ashamed about this: I just tried my code to send you the exact error the compiler gave me and as expected it work. I really don't know what I was doing yesterday with this.Quote:
Originally Posted by brewbuck
Thank you very much for your help. I'll try to make the plug in this way as it is the best way to do it.