Plugin Adapter Classes?

[wysota]

Although I'm not a big fan of adapter classes, this has the benefit of somewhat insulating the end user from changes to the interface, since additions to the interface will not require the user to modify and recompile their plugin code.

If I understand correctly what you mean then that's not true. Addition of a virtual method to a base class requires recompilation of all subclasses (as the virtual table size and possibly offsets change).

Note that we cannot include the Q_EXPORT_PLUGIN2 anywhere but in the "working" plugin.

Why not?

It cannot be included in the adapter class, because it can only occur once in any given library. But it seems that the loader won't recognize the plugin as valid unless it inherits directly from the abstract base class.

Naah, that's shouldn't be the case.

Any thoughts on how to accomplish this, or on whether it is even possible under the Qt plugin framework?

Please prepare a minimal compilable example reproducing the problem.

[SixDegrees]

[QUOTE

Why not?


[/QUOTE]

http://doc.trolltech.com/4.2/qtplugi...XPORT_PLUGIN2:

There should be exactly one occurrence of this macro in the source code for a Qt plugin, and it should be used where the implementation is written rather than in a header file.

[wysota]

Why not?

http://doc.trolltech.com/4.2/qtplugi...XPORT_PLUGIN2:

Sorry, I misunderstood you. I though you have written that you were unable to put it in the "working" plugin. You have to put it there, it wouldn't make sense to put it elsewhere.

I suspect that the Qt framework only allows inheritance directly from the abstract base class. At least, that seems to be the case in practice, as noted.

"Qt framework" has nothing to do with this. C++ enforces some rules but it is perfectly valid to inherit from an implementation of a pure abstract class.

class Interface {
public:
  virtual void func1() = 0;
  virtual void func2() = 0;
};
 
class Implementation : public Interface {
public:
  void func1() { printf("Implementation::func1();\n"); }
  void func2() { printf("Implementation::func2();\n"); }
};
 
class Inherited : public Implementation {
public:
  void func2() { printf("Inherited::func2();\n"); }
};

class Interface {
public:
  virtual void func1() = 0;
  virtual void func2() = 0;
};

class Implementation : public Interface {
public:
  void func1() { printf("Implementation::func1();\n"); }
  void func2() { printf("Implementation::func2();\n"); }
};

class Inherited : public Implementation {
public:
  void func2() { printf("Inherited::func2();\n"); }
};

To copy to clipboard, switch view to plain text mode 

You can do the same with Qt plugins, only that you have to remember you should inherit from QObject somewhere.

[SixDegrees]

Unfortunately, the loader won't recognize Inherited. As you mention, we put the export macro there, along with Q_OBJECT, per the instructions in the examples. Just for grins, we tried putting it in the Implementation class, too; when we did that, the loader would recognize Implementation, but not, of course, Inherited.

This doesn't break my heart; as I said originally, I don't care much for adapter classes, and not being able to do this isn't that big a deal.

You may be right about the offset issue, anyway. We've done something similar in "raw" C++, but only on Solaris. We may have gotten lucky and exploited a peculiarity of the Solaris linker that wouldn't travel well.

[wysota]

You must be doing something wrong - it works for me just fine. Attached you will find a working example - if you are using Linux, just run run.sh, otherwise you'll have to adjust the script first and replace LD_LIBRARY_PATH with an equivalent on your system.

Edit: please edit run.sh and remove "make clean" calls, it seems one of them breaks something.

[SixDegrees]

You must be doing something wrong - it works for me just fine. Attached you will find a working example - if you are using Linux, just run run.sh, otherwise you'll have to adjust the script first and replace LD_LIBRARY_PATH with an equivalent on your system.

Edit: please edit run.sh and remove "make clean" calls, it seems one of them breaks something.

Thanks for your time, but these examples are not implemented as plugins. Inheritance certainly works - it's C++, after all. But when I do use the same paradigm and try to implement it as a plugin, the plugin loader fails to recognize Inherited as a legitimate plugin.

[wysota]

Thanks for your time, but these examples are not implemented as plugins.

Yes, they are. Look at the .pro files - I'm not linking libinherited.so into the "main" program. I think libimpl.so could also be made a plugin but libinherited.so has to link against it nevertheless so it will act as a regular library too.

Edit: Just checked it, you can load libimpl.so as a plugin too, just remember about adding the proper export macro.