> On Jul 13, 2016, at 9:47 AM, Thiago Macieira <[email protected]> > wrote: > > Em quarta-feira, 13 de julho de 2016, às 10:44:13 PDT, Alexander Blasche > escreveu: >> Hi, >> >> Yesterday, I stumbled over a break in QtSerialBus due to the addition of new >> QTimer::setInterval(..) overloads in qtbase/dev. This was introduced by >> >> https://codereview.qt-project.org/#/c/160889/ >> >> Unfortunately this has the undesirable side effect that lines like: >> >> q->connect(q, &QModbusClient::timeoutChanged, element.timer.data(), >> &QTimer::setInterval); >> >> do not compile anymore. The function pointer to setInterval() becomes >> ambiguous. While the fix (https://codereview.qt-project.org/#/c/165034/) >> was not difficult once you know what is happening this can hit every >> customer and basically reduces the source compatibility promise into >> absurdity. >> >> While talking to several devs in the office I could not find a congruent >> opinion on this issue. Do we or even can we care? Do we have a policy? > > We do have this policy since 5.0 that we have to be careful about overloads > due to the connect syntax. The breakage was accidental and not intended. > > I did intend to add overloads, as they're nice to use, I just hadn't > considered the consequences. >
While I agree that we must be careful when adding new overloads, I think we can do better with QObject::connect as well. I played around with this patch today, it fixes the breakage that sparked this thread without any other modifications: https://codereview.qt-project.org/165505 There are obviously things to improve in this WIP patch, but I do believe we can make improvements by hinting to the compiler which member function it should choose. I’ll explore this some more unless someone has a clear reason not to go down this road. Cheers, Louai
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
