0

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?

KcFnMi
  • 5,516
  • 10
  • 62
  • 136
  • 1
    Basically, all slots should be designed with the expectation that they will also be called in a non connect context. Only those that do not, that is, slots that CANNOT be called in a non connect context require special attention. Therefore, even under your principles, it is quite reasonable that public slots are all over the place. I mean, how many slots in your code cannot be called in a non connect context? – ken May 28 '22 at 09:11
  • Slots are just methods and the "connect context" is imho even a greater reason to make them public, because connecting is in principle accessing them from the outside. – alagner May 28 '22 at 11:07

1 Answers1

1

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.

ixSci
  • 13,100
  • 5
  • 45
  • 79
  • What if we create an object and move it to another thread. Then, from the original thread, call a method (public slot) on that object. This is the kind of thing that should not happen, right? I'm about to think that making it a private slot will prevent that, only way to call the method will be through signal/slot. – KcFnMi May 28 '22 at 16:58
  • Yes, agree with the first phrase. But I think I'm calling private slots with the new syntax here, could you add a reference or an example to show how private slots cannot be called? – KcFnMi May 28 '22 at 17:04
  • Like any non-thread safe member function, you can't call it cross-thread. Private doesn't do anything here. Like I said, it is an interface. You don't make other interface functions private, do you? And regarding your second comment: you don't call anything in your post or comments. Show how you connect a private slot with the new syntax. You can't do it outside the class itself (or its friends). @KcFnMi – ixSci May 28 '22 at 17:15
  • My bad, just confirmed what you said – KcFnMi May 28 '22 at 17:53