Questions on property notifiers

x6herbius

I have a couple of questions relating to the way QProperty notify signals should be used. I understand that they are fired when the property value changes but, for a title property for example, I've seen two different types of signal:

@void titleChanged();
void titleChanged(const QString&);@

Is there any specific advantage of one over the other, or any situation in which either one would be preferred, or is it good practice to implement both? Personally my current issue is that if I implement the latter in a component of a larger object, I can't hook up the signal containing a parameter to the larger object's generic

@void objectChanged();@

signal without first going through a boilerplate slot like

@handleTitleChanged(const QString&) { emit objectChanged(); }@

This method works but gets irritatingly messy when a number of different types of notification, each with different parameters, need to be hooked up to one single object change notification.

Any opinions of more experienced Qt users than myself would be much appreciated.

Chris Kawa

There's no point in implementing them both. You can connect a slot that has fewer number of parameters than the signal, just not more. You don't need that wrapper.

I guess the choice which you implement depends on the property and how it's going to be used. In case of a title, when someone connects to that change signal it's reasonable to assume that he is interested in what that title is, so I'd go for a version with parameter. Sometimes the value is not that important but the fact that it changes is. But I'd say the parameter version is more general.

Implementing both of these is actually a bad idea, because one is superset of the other anyway and it actually makes the new connect syntax a mess. Compiler can't figure out which overload you want and so you need an ugly cast like this:
@
connect(sender, static_cast<(void)(SenderClass::*)(int)>(&SenderClass::signal), receiver, &ReceiverClass::slot);

//when there's only one the syntax is easier:
//slot can be parameterless even if signal has a parameter
connect(sender, &SenderClass::signal, receiver, &ReceiverClass::slot);
@