Quote Originally Posted by fullmetalcoder View Post
This is not a solution... the reason for plugin interfaces to be abstract is that it frees the plugin from dependency to an intermediate library storing implementations of methods that would be defined in the interface...
Strange, because Qt uses the exact same method for providing widget plugins for Designer... And as far as I know other component technologies (like COM) use that approach as well...

Using an abstract class limits the dependency to a single header file whereas using complex (i.e. non-abstract) classes that must be known to both the app and its plugins force to rely on an intermediate shared library which contains all base plugin classes specifications... (and believe me, this is not an easy way to go, even if its brings great power...)
But where does my approach violate any of the above mentioned statements? I don't see a problem for "Blah" being an abstract class declared in the same file as "SomeInterface"...