Solved How to decide whether a method should be a slot
-
While developing I find myself writing some method and thinking "this might be useful as a slot for some signal", and so declaring it in
slots:
. I have a fair number of methods declared as slots which I don't yet use as such, I don't know whether that's more than Qt developers would have put in if they were developing my code.Obviously if I need it now as a slot there's no debate. But if you don't actually have a use case yet, how do you decide whether or not it would be a good idea to declare it as a slot? Or do you never make it a slot until you actually need it (requires rebuild/breaks compatibility)?
-
I normally only declare as slot if I absolutely need it. Qt5 connection syntax made slots fall in terms of actual need to 1% of what they were before.
Having said that the overhead created by a slot is not super costly and, if unused, most of it can be optimised out by the compiler so it's not a big deal -
I mostly don't declare methods as slots anymore. Overhead, as small as it may be, whether in binary, parsing or mocing, is just unnecessary for me.
I use them when I need to query them from the meta object, which falls probably waaay under the 1% of cases @VRonin mentioned.Don't know about QML though as I'm not a user of it. Does it require C++ methods to be slots for something?
-
@Chris-Kawa said in How to decide whether a method should be a slot:
Does it require C++ methods to be slots for something?
Yes, QML can only access methods:
- declared as slots
- declared as
Q_INVOKABLE
- declared as part of a
Q_PROPERTY
-
@VRonin
Thanks; I may rethink then and remove a whole bunch of methods I have marked asslots:
because I think of them as potentially-slotty ;-)Qt5 connection syntax made slots fall in terms of actual need to 1% of what they were before.
I know how old syntax worked, but I've only ever used new syntax. Could you clarify how you mean this change affected the need to declare slots? Are you just talking about keeping the number down so that the
connect()
auto-complete doesn't offer too many? -
Disclaimer: probably over-simplifying.
Qt4 connection used string-lookup to decide what method to execute, declaring a method as slot was the only way to add it to this look-up list to be found. Qt5 connection allowed use use functors and function pointers directly so there is no need for the other overhead -
@VRonin
Ahh, so you mean old style you had to declare as slot else it wouldn't be found in lookup table, now you can get away with just call to non-slot-declared method, right?Looks like I was wrong when I said earlier
Are you just talking about keeping the number down so that the
connect()
auto-complete doesn't offer too many?Creator
connect()
only offers signals for the signal, that's what I was thinking of, it offers everything for the slot. -
Hi,
Outside of the overhead issue, one reason to keep declaring your functions as slots is to make the intent of your code clear. While you can indeed use function pointers, its always nice to make your code as easy as possible to be read and reasoned about.
-
@SGaist
Which is what I had been doing. Trouble is, I have ended up with a lot of methods beingslots
because I could see them being useful as such, though I don't use them that way yet, and I'm beginning to think I'm marking too many that way! -
In that case, only make slots of what you are actually using as slot. You can change that later on.