Simulate qobject_cast failure

Question

I have a pure virtual class A, on which I do

Q_DECLARE_INTERFACE(A, "org.something.A")

and I have a plugin implemented as a class B which inherits A and QObject, has as an interface A and implements all pure virtual methods of A

class B : public QObject, public A
{
    Q_OBJECT
    Q_INTERFACES(A)

    public:
        void someMethod();
}

and in the cpp :

Q_EXPORT_PLUGIN2(A, A)

This works well. In reality there are many different interfaces, and the core application (which I haven't written and on which I can't do big modifications) calls

qobject_cast<A *>(bPointer);

and checks the result to know if a certain plugin implements an interface.

All this works very well.

How ever, I'd like in the B class to determine at runtime whether or not I want to implement a certain interface.

The methods would always be implemented, but I would like sometimes make qobject_cast fail but determined at runtime (A single instance would always fail or succeed for the same interface).

This might sound strange, but the reason for this is I would like to add Python (or other languages) plugins. They would have a C++ wrapper. Their python source code would be stored using an rcc file. The c++ code should be the same for all python plugins.

The c++ wrapper would call a python method the determine which interfaces are implemented by the python code, and make qobject_cast fail if the python code doesn't implement to interface. The C++ wrapper class would implement all interface methods and forward the call to python, but only the ones which have casted succesfully would really be called.

It may be feasable by reimplementing QObject's meta related methods, but I don't know which.

I hope you understand what I try to do (although it's not very clear). Maybe there is a completly different way of doing this ?

Thanks

Answer 1

You cannot change qobject_cast behavior, using only public Qt APIs. Also note, that you can have only one plugin object instance for every plugin library.

A solution will be a plugin, working as factory and returning interfaces by request.