You are not logged in.
I've got a sort of plugin architecture, basically a few classes which inherit from class foo. There can be multiple layers of inheritance, most of them have sort of a foo->bar->plugin inheritance, where foo is the abstract base class.
For plugin A, the header looks something like this.
class A : public bar {
protected:
virtual void shared_task();
public:
A() { }
void other_task();
~A() { }
};
extern "C" alg_method* create() {
return new A;
}
extern "C" void destroy(foo* p) {
delete p;
}
The reason shared_task() is virtual is because I want to have a class B which inherits publicly from class A (with the same extern "C" lines). Is there a way to do this (have B inherit from A). I get problems because B also has to have the create() and destroy() functions, and so I can't link A.o when compiling B. If I don't link A.o, obviously I can't inherit from it.
The other thing I've thought about is creating class C which publicly inherits from A, so that the header for A (and its object file) don't have the create() and destroy() functions. Is this the only way to achieve what I want?
Edit: stupid typo...
Last edited by ngoonee (2010-10-22 09:13:41)
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
First of all: Why is there a B() constructor in class A? And what's the difference between the create() and destroy() functions of object files a.o and b.o?
And you can't overload the create() and destroy() functions and declare all of them 'extern "C"'. Have a look at this explanation and workaround:
http://developers.sun.com/solaris/artic … cpp_from_c
Last edited by ber_t (2010-10-22 08:45:45)
Offline
Sorry bout that, typo fixed. The create() function creates an instance of the plugin (A, or B, or whatever), the destroy() function deletes it. So obviously it would be return new B; for the second case.
I'll check out the link, thanks.
Edit: done that. Different topic to what I'm doing though. That link discusses extern "C", but my issue is more the creation of dynamic libraries (or plugins). http://stackoverflow.com/questions/4966 … y-on-linux is the only link I can find currently describing what I'm doing, but only a simple example (first answer).
Last edited by ngoonee (2010-10-22 09:18:17)
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Do I understand you correctly?: You want to be able to dynamically link to a plugin at runtime, e.g. a.so or b.so. Both of them contain the destroy() and create() function, which return a baseclass pointer to a newly allocated A/B object and provide different computations via a call of a virtual function.
A workaround would be to implement the functionality B has to inherit from class A in the header file of class A. But you have to move the create() and destroy() functions into a.cpp and b.cpp and compile b.so without using a.so, because of the conflicting functions.
EDIT: typo!
Last edited by ber_t (2010-10-22 10:31:42)
Offline
Exactly correct. I was afraid of this, I don't really want to put functionality in A.h. I guess this would also work if I had A1.cpp with all the functionality and A2.cpp which only inherits A1 and has the create() and destroy()?
Thanks for your help.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Of course, that will also do the trick. And it's a lot better, in case the functionality is big.
Basically, it's the same like a third class named C, which you mentioned in your first post, but this way you only divide the plugins into compilation units and not into different classes, what would be semantically wrong.
Offline