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] Bluetooth and NFC vs Reference Platforms
Hi Kate, -Original Message- From: Kate Alhola [mailto:kate.alh...@gmail.com] While you can get the pairing status for an arbitrary address you cannot get a list of a connected device. This requires additional API elements but certainly does not invalidate any API for 5.2 - it is a feature request. If you have a patch adding this please submit (to dev branch) . Otherwise please file a Jira item for it. I have a code for Bluez and Android that could be integrated as a patch but currently it is separate just because i wanted my application to be compatible with standard library, least in Linux. I Android Bluetooth needed so many bugfixes that I needed to have own copy patched of library.I found that there is Linux/Bluez code in https://qt.gitorious.org/qt/qtconnectivity but no Android ? Right now there is not Android support. However it is one of the things I wanted to tackle next. I was however considering to use the Android Java interfaces for the port (similar to QtSensors). The reason is the fact that Android does not always run Bluez. The Java API would provide the relevant layer without having to worry about Broadcom vs Bluez or whatever else. This work is tracked by QTBUG-33792. Could you possibly elaborate how you integrated it? Did you just deploy the Bluez backend to Android (plus some patches) and it worked? How do you cope with native Broadcom specific Bluetooth APIs? LBNL I have a question. While it is technically possible to do this I am somewhat at a loss for what use case I might need this. That's why it didn't even occur to me to expose those API elements until about 1-2 weeks ago (when somebody else asked for it). At that point it was too late for 5.2. Any help on my use case question? Very common use case, your application wants to use device X ( or device some compatible device ). If device is already paired,it could just ask list of known devices and use it. There is no sense that every time some application would like to sue some device, the device should put in discoverable mode application find it. I use it just so that I look is device X paired and if is, I use it. If not, then I ask user to put device discoverable pairing mode and pair it. Next time application find it automatically. Thank you for the explanation. I added it to the backlog as QTBUG-33791. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bluetooth and NFC vs Reference Platforms
Hi Tony, -Original Message- From: Tony Van Eerd [mailto:tvane...@blackberry.com] Sent: Tuesday, 1 October 2013 16:31 To: Kate Alhola; Blasche Alexander Cc: development@qt-project.org Subject: RE: [Development] Bluetooth and NFC vs Reference Platforms Overall, I expect that at some point in the future, we should have a higher-level device to device API. Both Bluetooth and NFC are too technology specific. New API for each new tech, or is there an abstraction to be had? QTBUG-33623 is the beginning of it. There is even an API draft on Gerrit. Right now it is NFC specific but it doesn't have to stay this way. Also, it may require a new library altogether as the share API may have to link to the various API's and I don't want QtNFC to link against QtBluetooth or vice versa or whatever other new transport media you can come up with. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Documentation todo for Qt 5.2
Hello, I'm curious to know if this is a heavily requested feature. Could you file a bug or request? We can have an annotated lists where the description taken from the \brief is in another column. QML Types - Module - Since also makes sense to me. The major issue is that the All Classes and All QML Types pages will be slower to load. Cheers, Jerome P. Documentation Engineer - Digia, Qt Fra: Mark [mark...@gmail.com] Sendt: 27. september 2013 18:42 To: Pasion Jerome Cc: development@qt-project.org Emne: Re: [Development] Documentation todo for Qt 5.2 On Fri, Sep 27, 2013 at 1:33 PM, Pasion Jerome jerome.pas...@digia.commailto:jerome.pas...@digia.com wrote: Hello all, Moving forward, this is a sanity check list related to documentation. I would like to get people to start looking at their content for missing documentation sooner than later. (I'm linking to the documentation from stable, but these should apply to all Qt 5 branches) Mainly: - New modules should be listed as either an Essential or an Add-On: http://doc-snapshot.qt-project.org/qt5-stable/qtmodules.html -Classes should be in the All Classes page: http://doc-snapshot.qt-project.org/qt5-stable/classes.html -QML types should be in the All QML Types page: http://doc-snapshot.qt-project.org/qt5-stable/qmltypes.html -pages should be accessible from the main page through the Overviews, Reference, and Getting Started sections. (Don't bury the pages so nobody can find them). -wiki material (which is convenient during the planning and development phases) should be ported over to the Qt reference so they get packaged with the installers. -the same requirements for every module still apply: landing page, C++ classes page, QML types page, examples, and overview. The requirements are in the Qt Writing Guidelines wiki. These points are also in the Qt Writing Guidelines: http://qt-project.org/wiki/QtWritingGuidelines including a checklist for adding documentation to a new module. We also have an umbrella bug report covering Qt 5.2 documentation issues: https://bugreports.qt-project.org/browse/QTBUG-32173 As always, feel free to ask questions or if your project has an exotic setup that we should know about. Cheers, Jerome P. Documentation Engineer - Digia, Qt ___ Development mailing list Development@qt-project.orgmailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Hi, I've browsed through the All QML types and All Classes, but i really miss an easy way to see when a specific class (or QML type) got added in Qt. Would it be possible to change it to something like this: All classes ASince QAbstractAnimation4.6 ... ... So just adding a Since column to give you a very easy fast overview of when a class got introduced. The same for QML types obviously. Cheers, Mark ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] ODP: Disabling exception support in QtCore?
Hi, (sorry for top posting) Small note, I believe that exception safety never really worked. It was almost not tested, so everyone depending on the feature was depending on an undefined behavior anyway. At the beginning of Qt5 I tried to improve the situation in our containers. I wrote a few tests, I fixed a few bugs, but it was like going through a swamp, slow and dirty. Getting a review was difficult, because such changes were increasing code size, binary size, were complex and the worst almost nobody cared. The amount of bugs was scary. Even our the best container QVector was not working correctly with exceptions. So removing exception support is not a functionality regression it is just acknowledging of the current state. Now, maybe in some places it works, but from a API user perspective it is gambling. I do not think we are able to have exception safety back, that requires a lot of commitment that I do not see. Personally, I used to like exceptions. It is sad that Qt is not supporting or really use them, but I believe that people can live without such support. std::bad_alloc, is it even possible to see it, when at least on Linux most of distros have memory overcommit enabled? Cheers, Jędrek Od: development-bounces+jedrzej.nowacki=digia@qt-project.org [development-bounces+jedrzej.nowacki=digia@qt-project.org] w imieniu Olivier Goffart [oliv...@woboq.com] Wysłano: 2 października 2013 09:09 Do: development@qt-project.org Cc: Thiago Macieira Temat: 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ODP: Disabling exception support in QtCore?
On 02.10.13 12:51, Nowacki Jedrzej jedrzej.nowa...@digia.com wrote: Hi, (sorry for top posting) Small note, I believe that exception safety never really worked. It was almost not tested, so everyone depending on the feature was depending on an undefined behavior anyway. At the beginning of Qt5 I tried to improve the situation in our containers. I wrote a few tests, I fixed a few bugs, but it was like going through a swamp, slow and dirty. Getting a review was difficult, because such changes were increasing code size, binary size, were complex and the worst almost nobody cared. The amount of bugs was scary. Even our the best container QVector was not working correctly with exceptions. So removing exception support is not a functionality regression it is just acknowledging of the current state. Now, maybe in some places it works, but from a API user perspective it is gambling. I do not think we are able to have exception safety back, that requires a lot of commitment that I do not see. I don't think anybody is asking to have exception safety for our containers. All we're talking about right now is signal/slot connections. Cheers, Lars Personally, I used to like exceptions. It is sad that Qt is not supporting or really use them, but I believe that people can live without such support. std::bad_alloc, is it even possible to see it, when at least on Linux most of distros have memory overcommit enabled? Cheers, Jędrek Od: development-bounces+jedrzej.nowacki=digia@qt-project.org [development-bounces+jedrzej.nowacki=digia@qt-project.org] w imieniu Olivier Goffart [oliv...@woboq.com] Wysłano: 2 października 2013 09:09 Do: development@qt-project.org Cc: Thiago Macieira Temat: 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 ___ 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] Documentation todo for Qt 5.2
On Wed, Oct 2, 2013 at 10:31 AM, Pasion Jerome jerome.pas...@digia.comwrote: Hello, I'm curious to know if this is a heavily requested feature. Could you file a bug or request? We can have an annotated lists where the description taken from the \brief is in another column. QML Types - Module - Since also makes sense to me. The major issue is that the All Classes and All QML Types pages will be slower to load. Cheers, Jerome P. Documentation Engineer - Digia, Qt -- *Fra:* Mark [mark...@gmail.com] *Sendt:* 27. september 2013 18:42 *To:* Pasion Jerome *Cc:* development@qt-project.org *Emne:* Re: [Development] Documentation todo for Qt 5.2 On Fri, Sep 27, 2013 at 1:33 PM, Pasion Jerome jerome.pas...@digia.comwrote: Hello all, Moving forward, this is a sanity check list related to documentation. I would like to get people to start looking at their content for missing documentation sooner than later. (I'm linking to the documentation from stable, but these should apply to all Qt 5 branches) Mainly: - New modules should be listed as either an Essential or an Add-On: http://doc-snapshot.qt-project.org/qt5-stable/qtmodules.html -Classes should be in the All Classes page: http://doc-snapshot.qt-project.org/qt5-stable/classes.html -QML types should be in the All QML Types page: http://doc-snapshot.qt-project.org/qt5-stable/qmltypes.html -pages should be accessible from the main page through the Overviews, Reference, and Getting Started sections. (Don't bury the pages so nobody can find them). -wiki material (which is convenient during the planning and development phases) should be ported over to the Qt reference so they get packaged with the installers. -the same requirements for every module still apply: landing page, C++ classes page, QML types page, examples, and overview. The requirements are in the Qt Writing Guidelines wiki. These points are also in the Qt Writing Guidelines: http://qt-project.org/wiki/QtWritingGuidelines including a checklist for adding documentation to a new module. We also have an umbrella bug report covering Qt 5.2 documentation issues: https://bugreports.qt-project.org/browse/QTBUG-32173 As always, feel free to ask questions or if your project has an exotic setup that we should know about. Cheers, Jerome P. Documentation Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Hi, I've browsed through the All QML types and All Classes, but i really miss an easy way to see when a specific class (or QML type) got added in Qt. Would it be possible to change it to something like this: All classes ASince QAbstractAnimation4.6 ... ... So just adding a Since column to give you a very easy fast overview of when a class got introduced. The same for QML types obviously. Cheers, Mark Done: https://bugreports.qt-project.org/browse/QTBUG-33823 If you have a second, please fix the title. I didn't check the title before posting the feature... ___ 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] Changing keyboard layouts in Qt 5.1 apps with GNOME
Sorry I'm bumping this , but it's a serious blocker for my app , and QtCreator usability problem under GNOME. Here's the reply I got from the GNOME team: https://mail.gnome.org/archives/desktop-devel-list/2013-September/msg00046.html Is there anything I can do to further diagnose the problem? Petko ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
