| Author |
 Topic  |
|
|
str
Junior Member
19 Posts |
 Posted - Mar 16 2021 : 06:07:20 AM
|
Hi,
there is a lot of old Qt code using something like
connect(sender, SIGNAL(editingFinished()), this, SLOT(zoomIndexChanged()));
It would be nice to automatically refactor this to modern style:
connect(sender, &Sender::editingFinished, this, &Receiver::zoomIndexChanged);
Best regards
Steffen |
Edited by - str on Mar 16 2021 10:45:42 AM |
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Mar 16 2021 : 07:41:26 AM
|
In the old format, the functions don't have their class names, but they do in the new format. Is this deliberate?
I am wondering how the functions were resolved if they didn't have class names in the old format. The main reason for asking is that if you don't need to look up the class names then this looks like it could be done quite easily with a careful regex find and replace. |
zen is the art of being at one with the two'ness |
 |
|
|
str
Junior Member
19 Posts |
Posted - Mar 16 2021 : 10:30:34 AM
|
The old format uses meta object logic (moc.exe) to resolve the function names. And yes, no class name are needed or allowed there.
The new format used normal c++ member function pointer syntax, where a class name is mandatory. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Mar 16 2021 : 12:21:41 PM
|
I have hunted up a sample project built with Qt, qftp:
http://hugo.pereira.free.fr/software/index.php?page=package&package_list=software_list_qt4&package=qftp&full=0
since I needed some examples to see what was going on here. I am seeing connect() with 3 or 4 parameters.
It looks like the rule is that with 4 parameters, we can get the required type of the 2nd parameter from the 1st parameter, and the required type of the 4th parameter from the 3rd parameter.
If there are only 3 parameters then the required type for the 3rd parameter is "this".
Am I understanding correctly? |
zen is the art of being at one with the two'ness |
|
|
|
str
Junior Member
19 Posts |
Posted - Mar 17 2021 : 10:43:17 AM
|
Yes, that's right.
But in case of 3 parameters, you also need to add 'this' as the 3rd argument. New syntax is only valid for 4 parameters.
If only 3 params are given, 3. argument is expected to be a Functor or lambda without any 'this'.
Also important:
If a signal has some overloads, you need something like:
connect(&m_senderMapper, SIGNAL(mapped(QObject *)), this, SLOT(objChanged(QObject *)));
connect(&m_senderMapper,QOverload<QObject *>::of(&QSignalMapper::mapped), this, &cParameterModel::objChanged); |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Mar 17 2021 : 1:33:45 PM
|
That is going to need more explaining, if you are after VA doing something like that.
I am happy to put in a feature request for the basic transformation / refactoring, since that seems to be well defined, and I can pin down a set of test cases to make sure it does what I expect it to do.
Looking in the FTP code, I have found the example:
connect(socket, SIGNAL(error(QAbstractSocket::SocketError)), SLOT(socketError(QAbstractSocket::SocketError)));
which is already "breaking" the simple refactoring rules. There are no results for a find in files for "mapped" in the FTP solution source code. |
zen is the art of being at one with the two'ness |
|
|
|
str
Junior Member
19 Posts |
Posted - Mar 18 2021 : 03:43:53 AM
|
What do you mean with 'mapped'? If you mean my example above, this is not from the ftp source code.
One example is in CustomSlider.cpp:
connect( spinBox_, SIGNAL(valueChanged(int)), SLOT(_updateSlider(int)) );
becomes to:
connect( spinBox_, &QSpinBox::valueChanged, this, &CustomSlider::_updateSlider );
But QSpinBox has two overloads of valueChanged (int or QString). Do, you need to tell the connect function which to use:
connect( spinBox_, QOverload<int>::of(&QSpinBox::valueChanged), this, &CustomSlider::_updateSlider );
or with C++14
connect( spinBox_, qOverload<int>(&QSpinBox::valueChanged), this, &CustomSlider::_updateSlider );
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Mar 18 2021 : 10:33:27 AM
|
What assumptions should we be making here? Reading up on this, qOverload was introduced in Qt 5.7, while this new syntax for connect was introduced in Qt 5, so do we just assume a suitable version of Qt, or do we need to start checking the version of the Qt library?
And this page doesn't even seem to mention QOverload::Of
https://wiki.qt.io/New_Signal_Slot_Syntax
Do you have a simple page that explains what is going on here that we can use as a clear guide for a feature request? Remember we don't use Qt internally, so have very limited knowledge of it. |
zen is the art of being at one with the two'ness |
|
|
|
str
Junior Member
19 Posts |
Posted - Mar 19 2021 : 03:45:13 AM
|
Maybe you could just warn, in case there is an overloaded signal available. This is quite a rare case.
It is also not directly related to Qt/connect, but comes from C++ function pointer concept, where overloading is not supported as well.
https://en.cppreference.com/w/cpp/language/overloaded_address
There case 6 needs exactly such a cast (which is done by qoverload a little bit nicer using templates) |
|
|
|
str
Junior Member
19 Posts |
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Mar 19 2021 : 10:07:05 AM
|
I think I have a clear sense of what is required here now, so I have put in a feature request:
case=144545
just be aware that this may not be looked at for quite some time, but you never know. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
Refactor Qt signal/slot
