Home > Net >  Should we prefer Qt's private slots over public slots?
Should we prefer Qt's private slots over public slots?

Time:05-29

Qt "private slots:" what is this?

AFAIK @Andrew's answer to the question above addresses the point. And @borges mentions the important detail

When the method is called via signal/slot mechanism, the access specifiers are ignored. But slots are also "normal" methods. When you call them using the traditional way, the access specifiers are considered

So I'm leaning towards write slots as private, in principle. And only mark them as public when the expectation is to also call them in a non connect context, I mean a direct call.

In other works, that will be like prefer private slots. However, I don't record having seen this kind of mentality on Qt's documentation. They seem to just use public slots everywhere. Am I missing something?

Does anything change when we do multithreading and a method (slot) might be called in an object which is in another thread?

CodePudding user response:

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.

  • Related