c++ - Qt signals and slots: permissions

Question

There are discrepancies between respected answers here on SO and the actual Qt docs.

I've read this question and I want some further clarification. Can anyone confirm:

• A signal is always protected, therefore it can be emitted only by the class or any of its subclasses. I'm not sure this is true; the question above shows answers supporting this statement. But the Qt docs say: Signals are public access functions and can be emitted from anywhere, but we recommend to only emit them from the class that defines the signal and its subclasses. So which is it?
• Slots are just functions, and thus may be public, private or protected. Obviously an outside class will have the ability to control if your class connects one of its own signals to one of its own slots if the slot is public. However, again the SO information differs from the docs, which say: a signal emitted from an instance of an arbitrary class can cause a private slot to be invoked in an instance of an unrelated class. This means that private is not honored by the signal/slot mechanism?
• The words public, private, protected have no use with working with the signal keyword
• The emitted signal is always available to all other classes, that is, any other class may always connect to that signal (regardless of its permission to emit the signal).
• Despite that all signals are viewable to by all classes, you could still have two classes with signals of the same name since the connect function takes the class name as a signal prefix (i.e. SomeClass::itsSignal)

Answer 1

• Signals are protected in Qt4 but are public in Qt5, thus the contradictory information.
• Slots are functions and public/protected/private is honored when calling them as such, when connecting to a signal, the metaobject system ignores it though.
• As signals is defined as public:, prepending them with e.g. private leads

to:

private:
public: //signals:
    void theSignal();

Thus it's without effect.

• All classes can be connected to any signal, correct. Signals are part of the public API in that regard.
• Having identical signal signatures is not a problem. The context is defined by the object specified as sender.

Using old-style connect:

Apple *apple ... Orange* orange
connect(apple, SIGNAL(changed()), this, SLOT(appleChanged()));
connect(orange, SIGNAL(changed()), this, SLOT(orangeChanged()));

The signal is specified as string here (without the class name in it), but as apple and orange have only one signal changed() each and the lookup is done in the metaobject of the QObject instance, which exists one per class (not instance), they cannot collide.

Qt 5 version with compile-time checking:

connect(apple, &Apple::changed, this, &MyReceiver::appleChanged);

Here one must specify a function, so depending on the scope, one must specify a class name (and maybe namespaces). As an ambiguous function name wouldn't be valid C++ and thus not compile, so one is safe here.