Le 05/10/2013 18:24, Olivier Goffart a écrit : (...) > As you may or may not know, it is a bit tricky to use the pointer based > connection syntax with overloaded signals or slot. > > If you do, say: > > connect(process, &QProcess::error; > this , &MyObject::processError); > > You get a compilation error looking like this > > error: no matching function for call to 'QObject::connect(QProcess*, > <unresolved overloaded function type>, ... > > Because QProcess::error is overloaded and the compiler can detect its type. > > They way around is to manually specify the type. This is a bit difficult, and > many developers get problem with it. Which is why I made a patch to qdoc to > always show an example. (...) > I would also like to remind that adding overloads to functions is not > source compatible, as it may break a connection using the function > pointer syntax. > Overloaded signals and slots should be avoided. (...)
Hi, I'm currently porting for the first time a Qt4 app to Qt5 and meanwhile discovering new great Qt5 features, therefore I'm far from beeing an expert. However my current opinion about Qt5 new connect syntaxes is that the one with functor is great¹ but the one with pointers to members, even though being nicer to read since we all dislike using macros, is in fact dangerous since not only hard to use (as you state many developers are not at ease with finding which class to prefix with) but also hard to maintain because e.g. (i) code reingeniering (remember that slots are not only defined in Qt framework classes but also in casual application code which is less stable) such as moving a slot from a class to its parent would break connections, and (ii) slot overloading change in a parent class is undetectable and will missconduct signals to undesired slot method. With macros these issues did not happen because meta object mechanisms support them through the characters string signature, which even support slots overloading in a convenient fashion (i.e. by preserving source compatibility even when overloading a slot method). In addition, I find slot overloading usefull, more precisely I find convenient to define a slot in a parent class on a virtual method and to overload it in relevant child classes without worrying with slot anymore. I say slot because you wanted to talk about slots but I do the same with non-slot Q_INVOKABLE methods when handling multithread invocations without signals or connections (through raw invokeMethod() calls). Finally, even though I find SIGNAL() and SLOT() macros not so beautifull than pointers to members, frankly, QtCreator does the completion so well and so painless that I forgot that there were macros in connect call until I read Qt5 release notes... Therefore, if I were a Qt project developer, not only I would not deprecate slot overloading, but if I were to choose between slot overloading and pointers to members connect, I would deprecate pointers to members connect. However I'm not a Qt project developer. And I may be wrong. And I know that calling for deprecating a brand new feature is somewhat heretic. Please don't burn me alive. Regards. ¹: especially with lambdas as soon as I will be able to afford being tight to C++11, which I'm not yet because of all that old linux distro with old gcc versions -- Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
