What's the difference?

[Atomic_Sheep]

Hi, I'm just wondering what the difference between the Qt documentation example:


signalMapper = new QSignalMapper(this);
signalMapper->setMapping(taxFileButton, QString("taxfile.txt"));
signalMapper->setMapping(accountFileButton, QString("accountsfile.txt"));
signalMapper->setMapping(reportFileButton, QString("reportfile.txt"));

connect(taxFileButton, SIGNAL(clicked()),
signalMapper, SLOT (map()));
connect(accountFileButton, SIGNAL(clicked()),
signalMapper, SLOT (map()));
connect(reportFileButton, SIGNAL(clicked()),
signalMapper, SLOT (map()));


connect(signalMapper, SIGNAL(mapped(QString)),
this, SLOT(readFile(QString)));

As opposed to having something like this would be?:

button.h

class Button : public QWidget
{
Q_OBJECT
public:
explicit Button(QWidget *parent = 0);

QString m_sName;

Button(QString sName) : m_sName(sName)
{}

signals:
void ButtonClicked(QString m_sName);
}


otherfile.cpp

{
//somewhere init something like 20 button classes.

void class::class_sSlot(QString name)
{
if(name == "a")
{
//do something
}
else if(name == "b")
{
//do something
}
//...etc for remaining 18 comparisons
}

Would there be a speed advantage of doing it the way it's presented in the Qt documentation over the second example?

[mvuori]

I would guess that there is no speed difference.

Now, the difference is in maintenance. The QSignalMapper brings the mappings (!) into plain view, in a declarative stype that is easy to modify when needed. The alternative style is a mess of code, logic and symbols. In fact, every time that one sees such a structure with 20 comparisons, the first thought should be: how can I get rid of all this code and just describe these mappins in some neat way; in a table or a list perhaps... and a list is exactly what QSignalMapper makes possible.

[ChrisW67]

The signal mapper has two signal/slot calls to make: button to mapper, lookup, mapper to slot. The other approach has two also: button clicked to button slot emitting ButtonClicked() to end slot. Not much difference.

You should only worry about tweaking performance when the program works and you have a measurable performance bottleneck... and then you work the bottleneck. Your CPU could probably process the signal and call the slot in the order of a thousand of times per second... how slow is the actual work of the slot in comparison?

[Atomic_Sheep]

Thanks, makes sense.