Use public slots or private slots?

[isaacEnrique]

I have some time working with Qt and I have always used private slots. I have never thought too much about it.

Currently, I have an application with several dialog boxes, which in turn have a number of widgets. The functionalities that must be executed when the user interacts with such widgets
are implemented as slots. Example: Clicking on a particular button zooms in on an image that is displayed.

Now I ask myself:

Is it correct that such slots are private?
Would it be of any use to make such public slots?
What is expected (standard) in these cases?

[koahnig]

@isaacEnrique

Well, slots are basically normal routines of your class, sicne you may use them also directly. Therefore, I would consider the private and public declaration as a matter of use and philosphy. If private is sufficient, I would use private slots. However, I am using slots across different classes and therefore, most of my slots are public.

[Venkatesh V]

@isaacEnrique

Hi...
there is no harm with using slot as a private member, if you are making use of those slots within the same class. it is just a normal member function there is nothing more than normal function... but if you want use those slot outside of the class then you should declare as a public slots.

[dheerendra]

In addition previous posts, private or public slots have no significance with Qt C++ environment if you are using slots in the context of signal-to-slot communication. If you are interested to call this slots as normal member function then public/private is applicable. Also if you are trying to call the slots from QML environment, then slots need to be public only.

[J.Hilk]

hi,
if you decide to use mostly the new syntax for Signal/Slot connection, it breaks the problem even more down to "should this function be public or private".

With the new syntax you actually do no longer need to specify a function as a SLOT, that part is now totaly ignored.
It is ignored by the compiler anyway as it is only used by the Q_OBJECT macro.

Howerver, it will make your header file much easier to read and understand, if you still do it.

[Roobarb]

This post is deleted!

[Roobarb]

@dheerendra But if you make the slot private, how can something outside of the slot class call connect() using it? When I try to use a private slot in my connect() call, the compiler says: error: 'onMessage' is a private member of 'my_slot'

[sierdzio]

@Roobarb said in Use public slots or private slots?:

@dheerendra But if you make the slot private, how can something outside of the slot class call connect() using it? When I try to use a private slot in my connect() call, the compiler says: error: 'onMessage' is a private member of 'my_slot'

You can use old connect syntax (SLOT macro), or invoke the slot via the QMetaObject, or call it via QML. All 3 will work even when a slot is private.

Lastly, you can make the connection inside the object which has the private slot :-) Then it is completely legal in C++.

[JonB]

@Roobarb
Naturally this is the case, it's just standard C++.
As @Venkatesh-V wrote above

but if you want use those slot outside of the class then you should declare as a public slots.

If you choose private then naturally you can only connect() to it from within the class. If you want to connect() from elsewhere it must be public.

[ @sierdzio comments are also true, but suggest you do not go down that route, no need, use new style syntax and stick with connect(). ]

[SGaist]

@Roobarb said in Use public slots or private slots?:

@dheerendra But if you make the slot private, how can something outside of the slot class call connect() using it? When I try to use a private slot in my connect() call, the compiler says: error: 'onMessage' is a private member of 'my_slot'

Hi,

That's where you have to properly analyze whether having that slot public is a valid use case or not. Just making it public because it allows connection is not a good reason. Check your architecture first.