Qt "Private Slots:" What Is This

Qt private slots: what is this?

Slots are a Qt-specific extension of C++. It only compiles after sending the code through Qt's preprocessor, the Meta-Object Compiler (moc). See http://doc.qt.io/qt-5/moc.html for documentation.

Edit: As Frank points out, moc is only required for linking. The extra keywords are #defined away with the standard preprocessor.

Should we prefer Qt's private slots over public slots?

Slots are a part of your class interface and thus should be public. Private slots are possible with the old connection syntax only due to the peculiarities of how the metasystem works. So they are a byproduct not some first-class citizens to support in the long run.

You also can't use the new connection syntax (which is preferred) if you have private slots because you need the pointer to the member function which you for no reason made private.

So no, you should not make slots private by default. Only if some specific need arises and with a comment of why you did it that way.

How to hide C++ Slot in Qml / Private Slots

Your premise is wrong

I don't want to expose a slot to QML, but is required to have a slot, because the slot is connected to internal signal.

Using the new Qt 5 connect syntax with pointer to member function you don't need a function to be a slot to be able to connect to it.

Just put your hideslot declaration in the private section of your class and you'll have what you want. It won't be exposed to QML and you would still be able to connect to it in C++.

As to why the private slot is exposed to QML, it is because all slots and Q_INVOKABLE functions are exposed to QML, regardless of their access.

Qt signals and slots: permissions

• 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.

---

Related Topics