Re: [Development] Disabling exception support in QtCore?
On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote: On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote: I dislike allowing this via the signal-slot mechanism because I see throwing from a slot as incompatible with the connection semantics. That would mean any signal could throw ANY exception. It would also preempt the execution of further slots, which might be important. Usually the person who connects a signal to a slot is a completely different developer than who wrote the signal or the slot. I think your assumptions are false. When using signals and slot in an application one write both the signal and the slot at the same time, to wire two part of that same appliation. That's not at all true. If it were, we wouldn't have signals or slots in our public API. If people were supposed to write the signals and the slots they connect, all our signals and slots would be private. I did not said that the signal and the slot were always written by the same person. And I explicitly said for an application, and you are talking about libraries. Since we have public signals and public slots and other libraries do the same, it stands to reason that a third-party is expected to connect them. Moreover, it stands to reason that a third-party might connect a fourth-party slot to one of our (first-party) signals. Your logic is flawed. The fact that some signals cannot be connected to slots that do not throw exceptions does not implies that no signals can be connected to slot that throw exceptions. When developing an application, developer who throw exceptionshould know what they are doing. It is not allowed to connect a signal from a exception unsafe class to a slot that may throw exception. But if they know that the class is exception safe, it should be allowed for them to connect signal from this class to slots that throw exceptions. That would mean people who do connections should have to pay attention to what slots throw and know what signals can cope with exceptions being thrown. Signals and slots are not different from normal functions in that respect (especially virtual functions) One need to take care who calls your function when you throw exceptions. I agree. Which is why I am saying that we need to establish rules for when exceptions would be allowed to escape a slot. Right now, our rule is: Qt code is noexcept. If your slot throws when called by Qt, the behaviour is undefined. If it throws when something else calls it, we make no statements. If you want to change that rule, then we can discuss it. I want to change that rule. Unles specified here, Qt code is noexcept. The only places where exceptions are allowed are: - Exceptions thrown by a slot are propagated to the signal connected with direct connection - Exceptions propagated through a call to invokeMethod are propagated from the method to the call - Exceptions thrown from QtConcurrent will be by re thrown when calling the QFuture API if the exception is a subclass of QException (Did I miss something?) -- 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 10 October 2013 15:14:02 André Somers wrote: Op 10-10-2013 14:53, Olivier Goffart schreef: On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote: On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote: I dislike allowing this via the signal-slot mechanism because I see throwing from a slot as incompatible with the connection semantics. That would mean any signal could throw ANY exception. It would also preempt the execution of further slots, which might be important. Usually the person who connects a signal to a slot is a completely different developer than who wrote the signal or the slot. I think your assumptions are false. When using signals and slot in an application one write both the signal and the slot at the same time, to wire two part of that same appliation. That's not at all true. If it were, we wouldn't have signals or slots in our public API. If people were supposed to write the signals and the slots they connect, all our signals and slots would be private. I did not said that the signal and the slot were always written by the same person. And I explicitly said for an application, and you are talking about libraries. Even for applications this statement is nonsense. For all but trivial applications that during their lifetime only get worked on by a single developer, the likelyhood of the same person always writing the slots for every signal goes to 0 rapidly with the age and number of developers on a project. That's not what I said. And regardless, I don't think it has any relevance for the problem in question. Within a code base that uses exception, developers should know which part of the code is exception safe and which part of the code can throw exception. And they know they should not call a function that can throw an exception from code that is not exception safe. (Hence they don't connect a signal from code that is not exception safe to a slot that throw an exception) -- 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, October 10, 2013 9:26 AM, Olivier Goffart oliv...@woboq.com wrote: On Thursday 10 October 2013 15:14:02 André Somers wrote: Op 10-10-2013 14:53, Olivier Goffart schreef: On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote: On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote: I dislike allowing this via the signal-slot mechanism because I see throwing from a slot as incompatible with the connection semantics. That would mean any signal could throw ANY exception. It would also preempt the execution of further slots, which might be important. Usually the person who connects a signal to a slot is a completely different developer than who wrote the signal or the slot. I think your assumptions are false. When using signals and slot in an application one write both the signal and the slot at the same time, to wire two part of that same appliation. That's not at all true. If it were, we wouldn't have signals or slots in our public API. If people were supposed to write the signals and the slots they connect, all our signals and slots would be private. I did not said that the signal and the slot were always written by the same person. And I explicitly said for an application, and you are talking about libraries. Even for applications this statement is nonsense. For all but trivial applications that during their lifetime only get worked on by a single developer, the likelyhood of the same person always writing the slots for every signal goes to 0 rapidly with the age and number of developers on a project. That's not what I said. It may not have been what you said, but it is what would occur. And regardless, I don't think it has any relevance for the problem in question. Quite relevant. Within a code base that uses exception, developers should know which part of the code is exception safe and which part of the code can throw exception. And they know they should not call a function that can throw an exception from code that is not exception safe. (Hence they don't connect a signal from code that is not exception safe to a slot that throw an exception) So now you have to a wrapper slot to wrap exceptions for any object from a library that you may interact with, or potentially any other code in your own project. I have personnally maintained a 400k+ SLOC codebase based on QT. It made extensive use of Signals/Slots between objects. Even though I was pretty much the only developer working on it, I still had to quite often track through signals/slots to make sure I understood things. Not because the codebase was unclear, but because it was quite non-trivial. It would have been an extensive PITA to try to know which ones I could or could not use exceptions with. I'm no compiler expert - but without help from the compiler to make sure that kind of things doesn't happen - e.g. marking signals/slots as Q_EXCEPTION_THROW and Q_EXCEPTION_SAFE and having some part of the compiler chain detect and at minimal warn of issues - it will not be feasible. $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Thursday 10 October 2013 08:22:44 BRM wrote: I have personnally maintained a 400k+ SLOC codebase based on QT. It made extensive use of Signals/Slots between objects. Even though I was pretty much the only developer working on it, I still had to quite often track through signals/slots to make sure I understood things. Not because the codebase was unclear, but because it was quite non-trivial. It would have been an extensive PITA to try to know which ones I could or could not use exceptions with. I'm no compiler expert - but without help from the compiler to make sure that kind of things doesn't happen - e.g. marking signals/slots as Q_EXCEPTION_THROW and Q_EXCEPTION_SAFE and having some part of the compiler chain detect and at minimal warn of issues - it will not be feasible. Programming is not easy. Now, our goal is to make programming with Qt as easy as possible. Tell me what makes programming easier: 1) We forbid any use of exception in any slot connected to any signal. - Programmers that don't use exceptions don't care because it does not impact them. - Programmers that uses exception in their application to forward errors cannot use signals and slots to propagate exceptions from one object of their application to another anymore. 2) We allow slots to forward the exception to the signal. - Programmers that don't use exceptions still don't care because it does not impact them. - Programmers that use exceptions can hapilly let exceptions go from the slot to where the signal is emitted. If you are not using exception now as I understand from your text above, then nothing changes for you. However, someone who is using currently exceptions, they will have to change their code for more complicated code because we decided to forbid it (for their own good) May I recall that exceptions through signals and slots always worked, and was used.And now you need to give a good reason to forbid it. Reducing the size of QtCore might be a good reason, but just saying it's for your own good is not. -- 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 10/10/13 6:02 PM, Olivier Goffart oliv...@woboq.com wrote: On Thursday 10 October 2013 08:22:44 BRM wrote: I have personnally maintained a 400k+ SLOC codebase based on QT. It made extensive use of Signals/Slots between objects. Even though I was pretty much the only developer working on it, I still had to quite often track through signals/slots to make sure I understood things. Not because the codebase was unclear, but because it was quite non-trivial. It would have been an extensive PITA to try to know which ones I could or could not use exceptions with. I'm no compiler expert - but without help from the compiler to make sure that kind of things doesn't happen - e.g. marking signals/slots as Q_EXCEPTION_THROW and Q_EXCEPTION_SAFE and having some part of the compiler chain detect and at minimal warn of issues - it will not be feasible. Programming is not easy. Now, our goal is to make programming with Qt as easy as possible. Tell me what makes programming easier: 1) We forbid any use of exception in any slot connected to any signal. - Programmers that don't use exceptions don't care because it does not impact them. - Programmers that uses exception in their application to forward errors cannot use signals and slots to propagate exceptions from one object of their application to another anymore. 2) We allow slots to forward the exception to the signal. - Programmers that don't use exceptions still don't care because it does not impact them. - Programmers that use exceptions can hapilly let exceptions go from the slot to where the signal is emitted. If you are not using exception now as I understand from your text above, then nothing changes for you. However, someone who is using currently exceptions, they will have to change their code for more complicated code because we decided to forbid it (for their own good) May I recall that exceptions through signals and slots always worked, and was used.And now you need to give a good reason to forbid it. Reducing the size of QtCore might be a good reason, but just saying it's for your own good is not. Agree with Olivier. Let's keep the level of support we had in Qt 4.x for throwing exceptions from slots: * It's undefined behaviour unless the place that emits the signal is prepared to catch the exception. * If a slot throws, no further slots connected to the signal will get called * throwing from any place that's connected to a signal defined in the Qt libraries leads to undefined behaviour The size reduction of QtCore is not a valid argument IMO. First of all we're talking about a number below 10%, and secondly this number could be reduced to almost 0 by making the build system for Qt Core only compile a few selected files with exception support enabled. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quinta-feira, 10 de outubro de 2013 13:54:09, Alex Malyushytskyy wrote: It never worked.with other than direct connections. As I see it there is a simple choice either to provide indirect connections or propagate exceptions to signal. Otherwise you always have to assume that every slot is called the way you can't let exception leave slot anyway. I don't mind complex rules. If anyone wants to use this feature, they have to know how it works. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ 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] Disabling exception support in QtCore?
On 2013-10-04 07:34, Kurt Pattyn wrote: In some markets like Avionics and Defense, it is simply forbidden for us to use exceptions. The only reason to forbid exceptions on technical (as opposed to uneducated or -worse- political) grounds is in hard real-time systems, because throwing an exception doesn't have a deterministic runtime in current implementations. But neither do malloc and operator new, so you will find that they tend to get banned together. I doubt that Qt will be used in a hard real-time environment with banned dynamic allocations anytime soon :) Thanks, Marc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Wednesday 02 October 2013 09:30:58 Thiago Macieira wrote: On quarta-feira, 2 de outubro de 2013 07:13:11, Knoll Lars wrote: +1. It's our decision not to use exceptions in Qt code, but I see quite a bit of value in being able to throw exceptions from a slot if that's the pattern a developer chooses to use. We've been doing quite a bit of work to allow this in Qt 4, and it's the main place where exception safety in Qt Core really makes sense IMO. Then please clarify the semantics. I really don't see this as a currently- valid use-case because it's not been specified. I dislike allowing this via the signal-slot mechanism because I see throwing from a slot as incompatible with the connection semantics. That would mean any signal could throw ANY exception. It would also preempt the execution of further slots, which might be important. Usually the person who connects a signal to a slot is a completely different developer than who wrote the signal or the slot. I think your assumptions are false. When using signals and slot in an application one write both the signal and the slot at the same time, to wire two part of that same appliation. That would mean people who do connections should have to pay attention to what slots throw and know what signals can cope with exceptions being thrown. Signals and slots are not different from normal functions in that respect (especially virtual functions) One need to take care who calls your function when you throw exceptions. I would accept at most exceptions through the invokeMethod mechanism in a DirectConnection, since that's a 1:1 relationship and there are no signals. -- 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?
I can add to this that Google also disallows exceptions, as is stated in their style guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Exceptions#Exceptions So, Qt is not alone in this regard. On 03 Oct 2013, at 12:00, development-requ...@qt-project.org wrote: From: Julien Blanc julien.bl...@nmc-company.fr Subject: Re: [Development] Disabling exception support in QtCore? Date: 3 Oct 2013 11:10:21 GMT+02:00 To: development@qt-project.org Le 03/10/2013 10:36, Olivier Goffart a écrit : On Wednesday 02 October 2013 09:30:58 Thiago Macieira wrote: That would mean any signal could throw ANY exception. It would also preempt the execution of further slots, which might be important. Usually the person who connects a signal to a slot is a completely different developer than who wrote the signal or the slot. I think your assumptions are false. When using signals and slot in an application one write both the signal and the slot at the same time, to wire two part of that same appliation. This may be true in a (small) application, but definitely not if you are developping a library. Usually, you write signals but don’t have any clue about the slots that will be connected to. That would mean people who do connections should have to pay attention to what slots throw and know what signals can cope with exceptions being thrown. Signals and slots are not different from normal functions in that respect (especially virtual functions) One need to take care who calls your function when you throw exceptions. That would mean that both slots and signals needs to document which exception they can respectively throw/handle. With qt5 we gained static checking of signal/slot compatibility. Introducing exceptions here would ruin this gain, since it will introduce a new way for signal and slots to be incompatible. And i don’t know how you can reasonably catch an exception in an asynchronous call. IMHO, slots should be nothrow. I would accept at most exceptions through the invokeMethod mechanism in a DirectConnection, since that's a 1:1 relationship and there are no signals. +1. Exceptions outside DirectConnection would be very strange animals. Julien ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote: I dislike allowing this via the signal-slot mechanism because I see throwing from a slot as incompatible with the connection semantics. That would mean any signal could throw ANY exception. It would also preempt the execution of further slots, which might be important. Usually the person who connects a signal to a slot is a completely different developer than who wrote the signal or the slot. I think your assumptions are false. When using signals and slot in an application one write both the signal and the slot at the same time, to wire two part of that same appliation. That's not at all true. If it were, we wouldn't have signals or slots in our public API. If people were supposed to write the signals and the slots they connect, all our signals and slots would be private. Since we have public signals and public slots and other libraries do the same, it stands to reason that a third-party is expected to connect them. Moreover, it stands to reason that a third-party might connect a fourth-party slot to one of our (first-party) signals. Said slot must not throw. Period. That would mean people who do connections should have to pay attention to what slots throw and know what signals can cope with exceptions being thrown. Signals and slots are not different from normal functions in that respect (especially virtual functions) One need to take care who calls your function when you throw exceptions. I agree. Which is why I am saying that we need to establish rules for when exceptions would be allowed to escape a slot. Right now, our rule is: Qt code is noexcept. If your slot throws when called by Qt, the behaviour is undefined. If it throws when something else calls it, we make no statements. If you want to change that rule, then we can discuss it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quinta-feira, 3 de outubro de 2013 09:43:18, Marc Mutz wrote: Qt is a general-purpose framework library. As a library, its *only* purpose is to serve its users; as a framework, it mandates a certain structure on programs using it. As a general-purpose library, it can only assume very little about how users of the library use the library. If those users want to use exceptions, which is still a standard C++ feature, last I checked, Qt should go out its way to enable those users, while at the same time giving users that _don't_ want exceptions a way to switch them off. I am assuming you mean users who want to use exceptions in their own code. That explicitly rules out using exceptions when interacting with Qt code. The only grey area is template code when used with a type from the user. Requiring a third-party library to support exceptions when they don't care is like asking a C library to support exceptions. Please point me to any discussion in Glib or APR or other generic C frameworks about them becoming exception-safe. Until then, we retain the right to make a decision whether exceptions can travel through our code, despite our choice of coding in C++. Our current decision is that they can't. Forcing users of Qt to choose between not using exceptions at all or writing try/catch blocks around the bodies of *all of their slots*, because we removed the single spot where (buggily) escaped exceptions could be centrally dealt with (main), is preposterous at best and arrogant at worst. I disagree. First, we establish an API contract. We provide the boundaries for which the API works and how it works, inside those boundaries. If you violate the boundaries, undefined behaviour occurs. Let's say, for the sake of argument, that one of those boundaries is that you will not throw back to Qt code. And let's assume developers are following that guidance, to the best of their knowledge. If an exception escapes because of a bug in the user code, then it's a BUG. All discussion about how things should behave is already out of the window. In addition, I also dispute the usefulness of a global try/catch in main(). What good is it to know that std::bad_cast or std::system_error happened, if you don't know where or what caused it? You're not going to display an error message to the user, there's nothing the user can do to correct the problem. You might say one would want to log the information for a developer to correct, but the catch block is too late already -- the stack has been unwound. The best thing you can actually have is a std::terminate() with a proper core dump. IMO, we should support throwing exceptions through the event loop. We don't (yet) have to guarantee that you can later re-enter the event loop again, even though that's a valid mid-term goal. And IMO, we shouldn't have to. I maintain that event-driven programming is incompatible with exceptions. Unless you can answer this question: what exceptions can a mouse press generate? Uhh, so there's the problem with Linux and The Single Distribution Build To Rule Them All. So what? Build separate libraries. Were doing so for debug support, too, and once upon a time, we did so for threads, until we found we want to use them in Qt, too, and started requiring them. Where are exceptions different? When Qt is part of the system API, there's only one Qt in the system. Choices are only available to application developers who bundle Qt with their applications. That's the feature system. When you have to interact with an existing system API, such as on Blackberry or Jolla or Ubuntu Phone devices, or on a KDE system, you don't have an option. Qt comes with the system, pre-built. You don't get to ask my application doesn't use threads or QProcess or QFileSystemWatcher, so please remove QThread from Qt. (As an aside: I just need to bring up Bjarne's quote from GoingNative this year where he - convincingly, I might add - argues that in every comparison of exception overhead, what is really being compared is code that handles all errors in a defined way (assuming at least the Basic Exception Guarantee is implemented in code) vs. code that handles no or only selected errors. IIRC, he goes on to say that equivalent code without exceptions would have both a higher runtime as well as a higher maintenance cost than the exception-using code. Incidentally, that's the guy that argued for -what?- 20 years that exceptions can be implemented with zero runtime overhead in the non-throwing case until Windows AMD64 finally implemented it that way, so I would not dare to dismiss this data point lightly). Thanks for the parentheses. But it's orthogonal to the discussion. Our numbers stand: 7% increase in code size because exceptions are enabled, on top of the non-exceptional error handling that already exists. Maybe the 7% is caused by our not having noexcept everywhere. -- Thiago Macieira - thiago.macieira (AT)
Re: [Development] Disabling exception support in QtCore?
On Fri, Oct 4, 2013 at 7:08 AM, Thiago Macieira thiago.macie...@intel.comwrote: 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. +1 to that. Though my opinion is that if we _have_ to have exceptions then don't make exceptions to where they can apply (pun intended!:)), like only to signal-slots that too with DirectConnection, otherwise it starts looking like a 'caveat' that users must remember. If possible, it should be either ALL or nothing. Also, is it so difficult to write code which is a mix of both, i.e interacting with libs which have exceptions and also with those that don't? I bet there's already a lot of s/w out there that uses libraries written by ppl from these 2 different schools of thought. (I've mostly been a user of Qt and have written my applications on embedded systems w/o feeling the need for exceptions, though my opinion might be biased as I came from a C programming background where we were used on the good ol' way of checking return values of fxns) -mandeep ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
2013/10/4 Kurt Pattyn pattyn.k...@gmail.com: In some markets like Avionics and Defense, it is simply forbidden for us to use exceptions. So, at least I think it should be possible to disable them in Qt if it was decided to allow them, otherwise we would be forced to use another framework. There's no way we would go from the current debates about whether exceptions should be allowed at all, to making exceptions *mandatory*. That will never happen. -- Nicolás ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quarta-feira, 2 de outubro de 2013 05:42:24, Knoll Lars wrote: On 01.10.13 23:23, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 1 de outubro de 2013 20:00:56, Knoll Lars wrote: Yes, signal/slot connections between user code should IMO still be able to pass through exceptions. I am afraid removing that will break code that's out there. This is already forbidden since 5.0. Is there any good reason why we don't support this, as we did in Qt 4? My goal of still compiling Qt Core with exceptions enabled was to allow for exactly this use case. Because we don't test it, so there's no guarantee that it works. In fact, I'd be surprised if it works at all. What's more, our types aren't exception-safe, even the container types. It's entirely unknown what will happen during a stack unwind. Personally, I don't want to maintain that functionality. And then there's the question: is it worth the 7% increase in code size? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quarta-feira, 2 de outubro de 2013 06:57:01, Thomas Sondergaard wrote: On 2013-10-01 21:20, Thiago Macieira wrote: Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? As an outside voice, I'd like to point out that the rest of the world is using exceptions and removing whatever exception support there is in QtCore seems like a step in the wrong direction. That's because they use exceptions in their API. We don't use it in ours. Also, our containers don't support types that throw exceptions. That decision was made three months ago. The question I posed is: given that the only remaining support is in the event loop, that its current working status is unknown, and that it costs us an increase of 7% in size of QtCore, is it worth it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Tuesday 01 October 2013 23:32:00 Thiago Macieira wrote: On quarta-feira, 2 de outubro de 2013 05:42:24, Knoll Lars wrote: On 01.10.13 23:23, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 1 de outubro de 2013 20:00:56, Knoll Lars wrote: Yes, signal/slot connections between user code should IMO still be able to pass through exceptions. I am afraid removing that will break code that's out there. This is already forbidden since 5.0. Is there any good reason why we don't support this, as we did in Qt 4? My goal of still compiling Qt Core with exceptions enabled was to allow for exactly this use case. Because we don't test it, so there's no guarantee that it works. In fact, I'd be surprised if it works at all. What's more, our types aren't exception-safe, even the container types. It's entirely unknown what will happen during a stack unwind. Personally, I don't want to maintain that functionality. And then there's the question: is it worth the 7% increase in code size? It is working. We even got bug report for some corner case where it did not, and I fixed those. (so they are used) There is no test because you did not want to have one. But we could easily add more auto tests. (It is really not that difficult) And it is forbidden only because you decided so, but it is not actually forbidden. I personally think letting exception go from the slot to the signal is a good feature (for the DirectConnection case). I am willing to maintain this functionality. Of course it is not allowed to throw an exception with QueuedConnection, or if the caller of the signal is not exception safe (all signals in Qt). And if a signal is connected to several slots, further slots are not going to be called. The only stack frame it needs to crosses are QMetaObject::activate, the moc generated code for signals or qt_metacall, and the templated helpers in qobject(defs)_impl.h. Could we perhaps only compile part of QtCore with exception support? Exceptions are not only about std::bad_alloc. I think it is unfortunuate that we removed support for user thrown exceptions from our container. (I agree that supporting bad_alloc is useless). But supporting throwing constructor and copy constructor in all the containers is a bit harder than in signals and slots. (And also less usefull) -- 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 02.10.13 09:09, Olivier Goffart oliv...@woboq.com wrote: On Tuesday 01 October 2013 23:32:00 Thiago Macieira wrote: On quarta-feira, 2 de outubro de 2013 05:42:24, Knoll Lars wrote: On 01.10.13 23:23, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 1 de outubro de 2013 20:00:56, Knoll Lars wrote: Yes, signal/slot connections between user code should IMO still be able to pass through exceptions. I am afraid removing that will break code that's out there. This is already forbidden since 5.0. Is there any good reason why we don't support this, as we did in Qt 4? My goal of still compiling Qt Core with exceptions enabled was to allow for exactly this use case. Because we don't test it, so there's no guarantee that it works. In fact, I'd be surprised if it works at all. What's more, our types aren't exception-safe, even the container types. It's entirely unknown what will happen during a stack unwind. Personally, I don't want to maintain that functionality. And then there's the question: is it worth the 7% increase in code size? It is working. We even got bug report for some corner case where it did not, and I fixed those. (so they are used) There is no test because you did not want to have one. But we could easily add more auto tests. (It is really not that difficult) And it is forbidden only because you decided so, but it is not actually forbidden. I personally think letting exception go from the slot to the signal is a good feature (for the DirectConnection case). I am willing to maintain this functionality. Of course it is not allowed to throw an exception with QueuedConnection, or if the caller of the signal is not exception safe (all signals in Qt). And if a signal is connected to several slots, further slots are not going to be called. The only stack frame it needs to crosses are QMetaObject::activate, the moc generated code for signals or qt_metacall, and the templated helpers in qobject(defs)_impl.h. Could we perhaps only compile part of QtCore with exception support? Exceptions are not only about std::bad_alloc. I think it is unfortunuate that we removed support for user thrown exceptions from our container. (I agree that supporting bad_alloc is useless). But supporting throwing constructor and copy constructor in all the containers is a bit harder than in signals and slots. (And also less usefull) +1. It's our decision not to use exceptions in Qt code, but I see quite a bit of value in being able to throw exceptions from a slot if that's the pattern a developer chooses to use. We've been doing quite a bit of work to allow this in Qt 4, and it's the main place where exception safety in Qt Core really makes sense IMO. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quarta-feira, 2 de outubro de 2013 07:13:11, Knoll Lars wrote: +1. It's our decision not to use exceptions in Qt code, but I see quite a bit of value in being able to throw exceptions from a slot if that's the pattern a developer chooses to use. We've been doing quite a bit of work to allow this in Qt 4, and it's the main place where exception safety in Qt Core really makes sense IMO. Then please clarify the semantics. I really don't see this as a currently- valid use-case because it's not been specified. I dislike allowing this via the signal-slot mechanism because I see throwing from a slot as incompatible with the connection semantics. That would mean any signal could throw ANY exception. It would also preempt the execution of further slots, which might be important. Usually the person who connects a signal to a slot is a completely different developer than who wrote the signal or the slot. That would mean people who do connections should have to pay attention to what slots throw and know what signals can cope with exceptions being thrown. I would accept at most exceptions through the invokeMethod mechanism in a DirectConnection, since that's a 1:1 relationship and there are no signals. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quarta-feira, 2 de outubro de 2013 09:09:16, Olivier Goffart wrote: It is working. We even got bug report for some corner case where it did not, and I fixed those. (so they are used) There is no test because you did not want to have one. But we could easily add more auto tests. (It is really not that difficult) And it is forbidden only because you decided so, but it is not actually forbidden. Circular definition. We agreed that it wasn't going to be supported, so I didn't want a test for something that we were allowed to break. We test the API contract, not the implementation. if we change our agreement that certain exceptions are allowed, then the tests for those conditions would be allowed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Wed, Oct 02, 2013 at 06:57:01AM +0200, Thomas Sondergaard wrote: On 2013-10-01 21:20, Thiago Macieira wrote: Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? As an outside voice, I'd like to point out that the rest of the world is using exceptions and removing whatever exception support there is in QtCore seems like a step in the wrong direction. Depends on what you define as rest of the world. If you mean by rest of the world other languages, like Java or Python, then yes, that world is using exceptions, and they are reasonable _there_. But if you check out what other C++ projects with Real World exposure do you'll find that they tend to be very cautious with exceptions - unless they simply outlaw them. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions is for instance pretty concise: We don't use C++ exceptions. They later give detailed reasoning and a conclusion including Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. [Side note: That's _exactly_ Qt's proposition: Being practically useful, not dogmatic.] http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions says In an effort to reduce code and executable size, LLVM does not use RTTI (e.g. dynamic_cast;) or exceptions. These two language features violate the general C++ principle of 'you only pay for what you use', causing executable bloat even if exceptions are never used in the code base, or if RTTI is never used for a class. Because of this, we turn them off globally in the code. Boost, which is not exactly notorious for old fashioned code, says at least on the topic of exception specifications some compilers turn off inlining if there is an exception-specification. Some compilers add try/catch blocks. Such pessimizations can be a performance disaster which makes the code unusable in practical applications (see http://www.boost.org/development/requirements.html#Exception-specification) Note that even the C++ Standard rolls back a part of the previous support for exceptions in C++11 by deprecating dynamic exception specifiers which turned out to be (surprise...) impractical, see 15.4.17/Annex D or e.g. http://www.gotw.ca/publications/mill22.htm for historic reasoning. Lesson learned here: Being allowed does not necessarily make it usable. Size overhead for just enabling exceptions is (of course depending on actual model/implementation) typically cited as 5-10%, which incidentally matches Thiago's findings for Qt Core rather well. That's a pretty high price for a single feature in general, and especially so if it does not add adequate value. In my book removing the need to pay for features one doesn't use is a Good Thing more often than not. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Wed, Oct 2, 2013 at 12:39 PM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Wed, Oct 02, 2013 at 06:57:01AM +0200, Thomas Sondergaard wrote: On 2013-10-01 21:20, Thiago Macieira wrote: Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? As an outside voice, I'd like to point out that the rest of the world is using exceptions and removing whatever exception support there is in QtCore seems like a step in the wrong direction. Depends on what you define as rest of the world. If you mean by rest of the world other languages, like Java or Python, then yes, that world is using exceptions, and they are reasonable _there_. But if you check out what other C++ projects with Real World exposure do you'll find that they tend to be very cautious with exceptions - unless they simply outlaw them. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions is for instance pretty concise: We don't use C++ exceptions. They later give detailed reasoning and a conclusion including Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. [Side note: That's _exactly_ Qt's proposition: Being practically useful, not dogmatic.] http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions says In an effort to reduce code and executable size, LLVM does not use RTTI (e.g. dynamic_cast;) or exceptions. These two language features violate the general C++ principle of 'you only pay for what you use', causing executable bloat even if exceptions are never used in the code base, or if RTTI is never used for a class. Because of this, we turn them off globally in the code. Boost, which is not exactly notorious for old fashioned code, says at least on the topic of exception specifications some compilers turn off inlining if there is an exception-specification. Some compilers add try/catch blocks. Such pessimizations can be a performance disaster which makes the code unusable in practical applications (see http://www.boost.org/development/requirements.html#Exception-specification ) Note that even the C++ Standard rolls back a part of the previous support for exceptions in C++11 by deprecating dynamic exception specifiers which turned out to be (surprise...) impractical, see 15.4.17/Annex D or e.g. http://www.gotw.ca/publications/mill22.htm for historic reasoning. Lesson learned here: Being allowed does not necessarily make it usable. Size overhead for just enabling exceptions is (of course depending on actual model/implementation) typically cited as 5-10%, which incidentally matches Thiago's findings for Qt Core rather well. That's a pretty high price for a single feature in general, and especially so if it does not add adequate value. In my book removing the need to pay for features one doesn't use is a Good Thing more often than not. Andre' +1 to Andre' I didn't trim his post because there's a lot there, and IMHO it's worth re-reading. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quarta-feira, 2 de outubro de 2013 20:39:25, André Pönitz wrote: Size overhead for just enabling exceptions is (of course depending on actual model/implementation) typically cited as 5-10%, which incidentally matches Thiago's findings for Qt Core rather well. That's a pretty high price for a single feature in general, and especially so if it does not add adequate value. In my book removing the need to pay for features one doesn't use is a Good Thing more often than not. Here's an interesting thought: What if the compiler would not intersperse the exception handler code with normal code? Right now, each generated function contains all the exceptional code paths from all cases, including inlined functions. If you read the disassembly of any C++ library, you'll see something like: function1: prologue body of the function epilogue (including return) exception code function2: prologue body of the function epilogue (including return) exception code That means the increase of 5-10% in code size on disk is translated a 5-10% increase in RAM usage too. What if all those exception code blocks were moved elsewhere? In that case, the increase on disk size might not be the same as the increase in RAM size. The exceptional code would be paged in only in case exceptions did actually get thrown. This is just a thought experiment. To implement it, we'd need an exception format that allowed two or more separate bodies for a function, a compiler option or pragma to tell the compiler that exceptions are unlikely, and a linker that cooperates. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
Hmm question - certainly worth it for sjlj platforms like 32-bit ios. One thing I'd love to see is the ability to throw exceptions through meta-call invocations (would be useful for qml, which uses exceptions) Simon Fra: Thiago Macieira Sendt: 21:20 tirsdag 1. oktober 2013 Til: development@qt-project.org Emne: [Development] Disabling exception support in QtCore? Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
Thiago wrote: Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? No, and yes. ;-)) I vote not worth it, I would disable exceptions in QtCore. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
Yes, signal/slot connections between user code should IMO still be able to pass through exceptions. I am afraid removing that will break code that's out there. Cheers, Lars On 10/1/13 9:31 PM, Hausmann Simon simon.hausm...@digia.com wrote: Hmm question - certainly worth it for sjlj platforms like 32-bit ios. One thing I'd love to see is the ability to throw exceptions through meta-call invocations (would be useful for qml, which uses exceptions) Simon Fra: Thiago Macieira Sendt: 21:20 tirsdag 1. oktober 2013 Til: development@qt-project.org Emne: [Development] Disabling exception support in QtCore? Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Tue, Oct 01, 2013 at 12:20:29PM -0700, Thiago Macieira wrote: Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Given that hoping that std::bad_alloc is thrown when expected and hoping that there's something that can be done about it when caught are rather futile exercises on common systems, keeping exception support only for that purpose does indeed not appear to be overly reasonable. So I am tempted to say not worth it. Should we disable exceptions in QtCore? Perhaps... do we have numbers how much the gain would actually be, say, for code size? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On terça-feira, 1 de outubro de 2013 19:31:05, Hausmann Simon wrote: Hmm question - certainly worth it for sjlj platforms like 32-bit ios. One thing I'd love to see is the ability to throw exceptions through meta-call invocations (would be useful for qml, which uses exceptions) The rule is: do not let exceptions propagate through Qt code. If you call qt_metacall directly (or, better, the static version), then the code is compiled with exceptions if they were enabled by the user code. In that case, it's safe to throw exceptions (provided that the class of the return type is also exception-safe). If you use the invokeMethod() machinery, it's not thread-safe today and not meant to be. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On terça-feira, 1 de outubro de 2013 20:00:56, Knoll Lars wrote: Yes, signal/slot connections between user code should IMO still be able to pass through exceptions. I am afraid removing that will break code that's out there. This is already forbidden since 5.0. You can throw from your slots, if you want. If you call them directly, you're responsible for catching the exception. However, it's undefined behaviour if you let the exception go back to QtCore code. The *best* you can hope for is that std::terminate is called. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On terça-feira, 1 de outubro de 2013 22:28:53, André Pönitz wrote: Perhaps... do we have numbers how much the gain would actually be, say, for code size? Give me an hour. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Tuesday 01 October 2013 21:20:29 Thiago Macieira wrote: Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? If it allows us to get a backtrace actually showing where the unhandled exception was thrown (instead of saying it was caused by the Qt event loop), I am all for disabling exception support in QtCore. -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On terça-feira, 1 de outubro de 2013 22:28:53, André Pönitz wrote: Perhaps... do we have numbers how much the gain would actually be, say, for code size? All numbers are based on my own QtCore tree, which contains a lot of patches on top of current stable, including protected visibility. I will not test the pristine tree. All builds are in release mode and the libraries have been stripped of debugging symbols (strip --strip-debug --strip-unneeded). The non-standard flags used were: GCC 4.7.2: -march=corei7-avx -std=c++0x -O3 -maccumulate-outgoing-args -flto GCC 4.8:.2 (same) ICC 14.0: -march=corei7-avx -O3 -std=c++0x Clang 3.3: -march=corei7-avx -O3 -std=c++11 Linker flags (all compilers): -Wl,-O1 -Wl,-z,relro -Wl,--as-needed The -O3 flag is enables optimisations that increase code size, which means this is probably skewed. It's highly unlikely that the exceptional codepath increases in size as much as the regular code path, though. Findings: - the .gcc_except_table section disappears - the .eh_frame and .eh_frame_hdr sections remain present, with negligible shrinkage for .eh_frame_hdr (except for ICC) - the size of the .text section shrinks by 5.7% - the size of the read-execute ELF segment reduces by 6.5% (same as reported by the /usr/bin/size tool) - the overall file size also reduces by 6.5%, which is expected since the read- only portion of QtCore is roughly 99% of the file size. (interestingly, the actual .text segment is only 57%) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center except-clang: There are 33 section headers, starting at offset 0x4cc1e0: Section Headers: [Nr] Name Type Addr Off Size ES Flags Lk Inf Al [ 0] NULL 0 0 0 0 [ 1] .dynsym DYNSYM 0238 0238 000210a8 24 A 2 2 8 [ 2] .dynstr STRTAB 000212e0 000212e0 00032a79 0 A 0 0 1 [ 3] .hashHASH 00053d60 00053d60 9830 4 A 1 0 8 [ 4] .gnu.version GNU_versym 0005d590 0005d590 2c0e 2 A 1 0 2 [ 5] .gnu.version_d GNU_verdef 000601a0 000601a0 001c 0 A 2 1 4 [ 6] .gnu.version_r GNU_verneed 000601bc 000601bc 0160 0 A 2 7 4 [ 7] .rela.dynRELA 00060320 00060320 00019470 24 A 1 0 8 [ 8] .rela.pltRELA 00079790 00079790 19f8 24 A 1 10 8 [ 9] .initPROGBITS 0007b188 0007b188 000e 0 AX 0 0 4 [10] .plt PROGBITS 0007b1a0 0007b1a0 1160 16 AX 0 0 16 [11] .textPROGBITS 0007c300 0007c300 002b1a30 0 AX 0 0 16 [12] .finiPROGBITS 0032dd30 0032dd30 0009 0 AX 0 0 4 [13] .gcc_except_tablePROGBITS 0032dd3c 0032dd3c 0003c454 0 A 0 0 4 [14] .rodata PROGBITS 0036a1a0 0036a1a0 00103d63 0 A 0 0 32 [15] .interp PROGBITS 0046df10 0046df10 001c 0 A 0 0 16 [16] .eh_framePROGBITS 0046df30 0046df30 00042dac 0 A 0 0 8 [17] .eh_frame_hdrPROGBITS 004b0cdc 004b0cdc eb04 0 A 0 0 4 [18] .tbssNOBITS 004c17b0 004c07b0 0008 0 WAT0 0 8 [19] .data.rel.ro.local PROGBITS 004c17b0 004c07b0 38f8 0 WA 0 0 16 [20] .jcr PROGBITS 004c50a8 004c40a8 0008 0 WA 0 0 8 [21] .data.rel.ro PROGBITS 004c50b0 004c40b0 6ac8 0 WA 0 0 16 [22] .dynamic DYNAMIC 004cbb78 004cab78 02b0 16 WA 2 0 8 [23] .got PROGBITS 004cbe30 004cae30 01b8 0 WA 0 0 8 [24] .got.plt PROGBITS 004cbfe8 004cafe8 08c0 0 WA 0 0 8 [25] .dataPROGBITS 004cc8b0 004cb8b0 0770 0 WA 0 0 16 [26] .tm_clone_table PROGBITS 004cd020 004cc020 0 WA 0 0 8 [27] .fini_array FINI_ARRAY 004cd020 004cc020 0010 0 WA 0 0 8 [28] .init_array INIT_ARRAY 004cd030 004cc030 0020 0 WA 0 0 8 [29] .bss NOBITS 004cd050 004cc050 18a0 0 WA 0 0 16 [30] .comment PROGBITS 004cc050 002d 1 MS 0 0 1 [31] .note.gnu.gold-version NOTE 004cc080 001c 0 0 0 4 [32] .shstrtabSTRTAB 004cc09c 0141 0 0 0 1 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg
Re: [Development] Disabling exception support in QtCore?
On quarta-feira, 2 de outubro de 2013 00:04:58, Christoph Feck wrote: On Tuesday 01 October 2013 21:20:29 Thiago Macieira wrote: Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? If it allows us to get a backtrace actually showing where the unhandled exception was thrown (instead of saying it was caused by the Qt event loop), I am all for disabling exception support in QtCore. In order to properly do that, we should remove all try/catch blocks in QtCore and replace with scoped pointers and scoped values. We should let the destructors handle the cleanup. Turning exceptions off may or may not get you the backtrace. It may also get you a std::terminate or a crash. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Wednesday 02 October 2013 00:41:56 Thiago Macieira wrote: On quarta-feira, 2 de outubro de 2013 00:04:58, Christoph Feck wrote: On Tuesday 01 October 2013 21:20:29 Thiago Macieira wrote: Should we disable exceptions in QtCore? If it allows us to get a backtrace actually showing where the unhandled exception was thrown (instead of saying it was caused by the Qt event loop), I am all for disabling exception support in QtCore. In order to properly do that, we should remove all try/catch blocks in QtCore and replace with scoped pointers and scoped values. We should let the destructors handle the cleanup. Sounds a bit more work than simply disabling exceptions, so might be something out of scope for 5.x. Turning exceptions off may or may not get you the backtrace. It may also get you a std::terminate or a crash. A crash is fine, as long as I see the origin, or are you implying that those crashes would record no backtrace at all? For example, https://bugs.kde.org/show_bug.cgi?id=325360 shows the backtrace of a re-thrown exception, but unless there are reproducible steps, the report is useless, because the trace originates from the event loop. We have hundreds of those reports, and the hope to find a reporter who can follow linked gdb instructions is next to zero. Christoph Feck (kdepepo) KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quarta-feira, 2 de outubro de 2013 01:03:19, Christoph Feck wrote: In order to properly do that, we should remove all try/catch blocks in QtCore and replace with scoped pointers and scoped values. We should let the destructors handle the cleanup. Sounds a bit more work than simply disabling exceptions, so might be something out of scope for 5.x. Not really. It just takes some work to do it. Turning exceptions off may or may not get you the backtrace. It may also get you a std::terminate or a crash. A crash is fine, as long as I see the origin, or are you implying that those crashes would record no backtrace at all? They may not record anything at all. You may see only ??? in the backtrace. This is *really* undefined behaviour territory. I can't even guess what the ABIs do if they face a frame with no exception information. Also note the discovery of the other email: the frame information is *still* present in the no-exception build. So it's quite likely that the IA-64 C++ ABI would at least manage to unwind the stack. However, after that, QtCore might be totally and utterly useless. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On 2013-10-01 21:20, Thiago Macieira wrote: Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? As an outside voice, I'd like to point out that the rest of the world is using exceptions and removing whatever exception support there is in QtCore seems like a step in the wrong direction. Regards, Thomas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On 01.10.13 23:23, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 1 de outubro de 2013 20:00:56, Knoll Lars wrote: Yes, signal/slot connections between user code should IMO still be able to pass through exceptions. I am afraid removing that will break code that's out there. This is already forbidden since 5.0. Is there any good reason why we don't support this, as we did in Qt 4? My goal of still compiling Qt Core with exceptions enabled was to allow for exactly this use case. Lars You can throw from your slots, if you want. If you call them directly, you're responsible for catching the exception. However, it's undefined behaviour if you let the exception go back to QtCore code. The *best* you can hope for is that std::terminate is called. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
