Re: [Development] [RFC] What to do about overloaded signals/slots?
Hi, > Op 5 okt. 2013 om 20:47 heeft Olivier Goffart het > volgende geschreven: > > > There is the same problem if one use pointer to member function in > QtConcurrent[1] or in other third party API (boost::bind) > Which means adding an overload can be a source incompatible change regardless > if it is used as a slot or not. To me, it means that using an (unqualified) member function pointer exposes you to source incompatibilities. It seems that that is a more general problem than with just Qt. We should document/warn against that effect and how to protect yourself from it, but IMHO it should not stop us from improving the API, even if that means adding overloads. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [RFC] What to do about overloaded signals/slots?
On Saturday 05 October 2013 19:18:29 André Somers wrote: > > Op 5 okt. 2013 om 18:24 heeft Olivier Goffart het > > volgende geschreven: > > > > I would also like to remind that adding overloads to functions is not > > source compatible, as it may break a connection using the function > > poitner syntax. Overloaded signals and slots should be avoided. > > Well, isn't this really the case for _all_ overloads then? Yes, that's true. > As with the new syntax signals can be connected to any method and not only > slots, introducing any overload is potentially source incompatible. So, this > rule seems rather inadequate. To me, it sounds like the recommended policy > should be to *always* specify the type in the new connection syntax > instead. Otherwise I don't see how you can ever stay source compatible > without limiting the development of the Qt API too much. There is the same problem if one use pointer to member function in QtConcurrent[1] or in other third party API (boost::bind) Which means adding an overload can be a source incompatible change regardless if it is used as a slot or not. [1] https://bugreports.qt-project.org/browse/QTBUG-12897 -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Thursday 03 October 2013 18:38:44 Thiago Macieira wrote: > On quinta-feira, 3 de outubro de 2013 17:11:54, Alex Malyushytskyy wrote: > > Assuming exceptions are enabled for signal/slots what is going to happen > > with Qt::QueuedConnection? > > As far as I understand at this point you can't catch exception in the > > signal. > > If we choose to standardise that exceptions are allowed from slots and they > propagate back to the emitter, that will still only apply to direct > connections. > > Any type of queued connection (blocking or not) is totally and utterly > incompatible with exceptions. Throw from a slot that was called via a queued > connection and it's now the event loop that will catch it. > > At that point we enter the other argument: are exceptions allowed to travel > through the event loop code? If we decide that they aren't, then this is > undefined behaviour and the application is allowed to crash. > > If we decide that they are, then the event loop will exit, returning the > control back to the caller of exec(), potentially terminating the thread or > the application if run() or main() don't catch it. > > > That means you will have to do it in the event loop. What is going to > > happen next? Re-throw it and an uncaught exception again? > > > > In this case I would prefer to make sure exception never leaves the slot. > > That's my argument. > > To summarise: > > 1) exceptions causing the event loop to exit do not make sense. The API to > make the event loop to exit is quit(), not an exception. Besides, I question > the usefulness of a global try/catch in main() or around an event loop. > > 2) given (1), exceptions must never be thrown from a slot that was called > via QueuedConnection or BlockingQueuedConnection. > > 3) given (2), if we allowed exceptions, users would have to take care that > they are thrown only during DirectConnection. That implies that (potentially > other) users must know which exceptions every slot throws, so that they can > decide whether they can connect to a given signal or connect via queued > connections. Therefore, I would advise against this, but I will not put > strong opposition against it. > > 4) if we decide to build QtCore with exception support after all, I would > agree that invokeMethod() should be strongly exception-safe, though I am not > volunteering to write that code, review it or bugfix it; though as a > maintainer I might be called into fixing it if it falls into bitrot. > > The questions now are: > a) do we have volunteers to write the code, unit tests and documentation > for direct connection slot throws, and maintain it? > b) is the cost worth the effort? > > To answer (b), I'd like someone to test our major platforms to see what > happens when an exception is thrown through code built with -fno-exceptions. > Given that the .eh_frame sections are still present, there's a chance that > it *works*. See also -funwind-tables. I do volounteer: That part of the code is already exception safe so the only thing to do is to have the unit test. Unit tests are there: https://codereview.qt-project.org/67361 https://codereview.qt-project.org/67362 For the documentation, I would refer to Mitch's old attempt. https://codereview.qt-project.org/41179 (I presonally think this explain too much, but well) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [RFC] What to do about overloaded signals/slots?
> Op 5 okt. 2013 om 18:24 heeft Olivier Goffart het > volgende geschreven: > > I would also like to remind that adding overloads to functions is not source > compatible, as it may break a connection using the function poitner syntax. > Overloaded signals and slots should be avoided. > Well, isn't this really the case for _all_ overloads then? As with the new syntax signals can be connected to any method and not only slots, introducing any overload is potentially source incompatible. So, this rule seems rather inadequate. To me, it sounds like the recommended policy should be to *always* specify the type in the new connection syntax instead. Otherwise I don't see how you can ever stay source compatible without limiting the development of the Qt API too much. Forbidding introducing overloads everywhere doesn't sound like a good idea to me, but only guaranteeing source compatibility if you use the full syntax specifying types sounds reasonable. You can choose to omit them, at the cost of having to fix some connects sometimes when changing Qt versions. That would also lift your rule above again. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [RFC] What to do about overloaded signals/slots?
Hi,
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*,
, ...
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.
https://codereview.qt-project.org/67348
This will add, for each overloaded signal a note like:
"
Note:This signal is overloaded with another member this class. In order to
connect to this signal using the function pointer syntax, you need to help the
compiler by specifying the type of the signal. Example:
connect(process, static_cast(&QProcess::error),
[=](QProcess::ProcessError error){ /* ... */ });
"
This is only for signal and not for slots. And I used in the example a
static_cast to specify the type. The adventage with this approach is that it
works both for the signal and the slot. But there are other ways.
Specifying the template parameter:
connect(process, &QProcess::error,
[=](QProcess::ProcessError error){ /* ... */ });
This is actually shorter to type. But for slot you would need to speficy both
the type of the signal and of the slot.
Which one should we recommand? Should we come to a macro?
Should the documentation also show a message for the slots that have
overloads?
I would also like to remind that adding overloads to functions is not source
compatible, as it may break a connection using the function poitner syntax.
Overloaded signals and slots should be avoided.
And another note: I see that Qt's source code does not make much use yet of
the new syntax. I would like to recommand using it as it allow to catch more
errors at compile time.
--
Olivier
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
