Signal and slot access specifiers

As mentioned earlier, you should only emit signals from the class that owns it or from its subclasses. However, if signals were really protected or private, you would not be able to connect to them using the pointer-to-member function syntax. To make such connections possible, signals are made public functions. This means that the compiler won't stop you from calling the signal from outside. If you want to prevent such calls, you can declare QPrivateSignal as the last argument of the signal:

signals:
void valueChanged(int value, QPrivateSignal);

QPrivateSignal is a private struct created in each QObject subclass by the Q_OBJECT macro, so you can only create QPrivateSignal objects in the current class.

Slots can be public, protected, or private, depending on how you want to restrict access to them. When using the pointer to a member function syntax for connection, you will only be able to create pointers to slots if you have access to them. It's also correct to call a slot directly from any other location as long as you have access to it.

That being said, Qt doesn't really support restricting access to signals and slots. Regardless of how a signal or a slot is declared, you can always access it using the old connect syntax. You can also call any signal or slot using the QMetaObject::invokeMethod method. While you can restrict direct C++ calls to reduce the possibility of errors, keep in mind that the users of your API still can access any signal or slot if they really want to.

There are some aspects of signals and slots that we have not covered here. We will discuss them later when we deal with multithreading ( Online Chapter,  https://www.packtpub.com/sites/default/files/downloads/MiscellaneousandAdvancedConcepts.pdf).