External Acces to Private Slot

[stefanadelbert]

You all make valid points. I'm definitely not criticizing Qt's SIGNAL / SLOT mechanism.

My observation is merely that class A would be able to execute a private slot on class B. There is no way that class B can prevent its private slot (which is actually just a private function that is registered as part of the associated metaObject) from being run by any other SIGNAL / SLOT aware class.

Say for instance that I want to create a private slot on class B that should only be run by class B:

class B : public QObject
{
private slots:
    void MyVeryPrivatePersonalSlot(); // I, class B, should be the only class able to run the code in this function
}

class B : public QObject
{
private slots:
    void MyVeryPrivatePersonalSlot(); // I, class B, should be the only class able to run the code in this function
}

To copy to clipboard, switch view to plain text mode 

But the private slot can be "called" (or triggered) by any class that can emit signals. So really the slot is not private at all.

class A : public QObject
{
    A() {
        instanceOfB = new B();
        connect(this, SIGNAL(mySignal()), instanceOfB, SLOT(MyVeryPrivatePersonalSlot()));
    }
 
signals:
    void mySignal();
 
private:
    B* instanceOfB;
}

class A : public QObject
{
    A() {
        instanceOfB = new B();
        connect(this, SIGNAL(mySignal()), instanceOfB, SLOT(MyVeryPrivatePersonalSlot()));
    }

signals:
    void mySignal();

private:
    B* instanceOfB;
}

To copy to clipboard, switch view to plain text mode 

Is there any way to prevent this behaviour, i.e. keep private slots truly private?

Signal-Slot pattern aim is that the sender DOESN'T KNOW which slots will be called via its signal.
so actually the sender doesn't call the slot, he just emits the signal and the environment deals with it.

I agree with you and this is all well and good when slot bar() is public. But when slot bar() is private, class B has no control over who can trigger the execution of the private slot's code.

Signal-Slot pattern aim is that the sender DOESN'T KNOW which slots will be called via its signal.
so actually the sender doesn't call the slot, he just emits the signal and the environment deals with it.

But in the case when class A, the sender (signaller), connect's its signal to class B's private slot (as in my example), then it does know exactly which function should be executed and it can choose to have code in private functions executed. In C++ this can be achieved using friends, but still class B would decide who its friends are so it still have the control.

I understand that the code isn't being called directly - it's being done through the metaObject framework, but the end effect is that a private function is exposed.

slots are not a usual functions. they are a part of metaObject. when you emitting signal slot is not called directly like this

obj->slotName( params );

obj->slotName( params );

To copy to clipboard, switch view to plain text mode 

emitting signal say to object to call it's function like this:

obj->invokeMethod( "slotName" // you see - in quotes
                              , params );

obj->invokeMethod( "slotName" // you see - in quotes
                              , params );

To copy to clipboard, switch view to plain text mode 

I agree and it's useful framework and I do understand (more or less) how the framework actually works. My concern is that private slots are available to anyone and everyone, and this breaks part of the C++ class member access pattern.

You can't call the slot directly, but you can call it via the slot mechanism as those are resolved during run time.

I disagree, but I'm very happy to be proved wrong.

A slot is nothing other than a function on a class and can be called the same way that any other function on a class would be called. But it is also considered when building the metaObject and is made available through the signal / slot mechanism. When the slot is called as a normal function the access specifier (public, protected, private) is respected. When the slot is triggered by a signal (whether the class' own signal or a signal from another class), the access specifier is not respected, resulting in private functions (slots) being runnable (triggerable) from outside the class.

The net effect is that private slots can be run by anyone.