Re: [Development] Disabling exception support in QtCore?
2013/10/4 Kurt Pattyn : > 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] QtBase_stable in CI broken down
Builds are running again. The same problem also occurred for QtDeclarative_stable, but that one is fixed as well. However, since we don't know the root cause for this problem we had, we can't say it won't happen again. We'll keep our eyes open... -Tony From: Sarajärvi Tony Sent: 3. lokakuuta 2013 12:20 To: development@qt-project.org Subject: QtBase_stable in CI broken down We have a problem in Gerrit releated to QtBase_stable. We know what has gone wrong, but we don't know how that's possible, nor how to fix it properly. Needless to say, investigation is ongoing. Thank you for your patience. -Tony Tony Sarajärvi CI Tech Lead Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
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. Aside from that, and that is personal, I really like having exception free code. Signals are a much nicer alternative, AND we can run tests to see if they are all connected (again a requirement from the Avionics world: all errors must be explicitly handled). With exceptions this is much more difficult, if not impossible. Besides that, using exceptions can lead to some very strange, difficult to detect bugs, especially in applications having an event loop, and multiple threads. So, a +1 from me to avoid exceptions. > On 04 Oct 2013, at 07:12, Mandeep Sandhu wrote: > > >> On Fri, Oct 4, 2013 at 7:08 AM, 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. >> > > +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?
On Fri, Oct 4, 2013 at 7:08 AM, 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. > > +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?
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. -- 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?
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. 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. Alex On Thu, Oct 3, 2013 at 11:08 AM, Thiago Macieira wrote: > 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 h
Re: [Development] Nokia/Digia copyright in PDF produced by QPrinter
Hi, Intention is not to claim copyright to your document. Please make a bug report on this and we'll take a look into if this needs to be altered or not. Yours, Tuukka Lähettäjä: development-bounces+tuukka.turunen=digia@qt-project.org [development-bounces+tuukka.turunen=digia@qt-project.org] käyttäjän Jeff Kehres [jkeh...@blackberry.com] puolesta Lähetetty: 3. lokakuuta 2013 17:30 Vastaanottaja: development@qt-project.org Aihe: [Development] Nokia/Digia copyright in PDF produced by QPrinter I'm using QPrinter in Qt 4.8 to produce a PDF document. In the metadata of the generated file (specifically the producer field) there is a Nokia copyright: (C) 2011 Nokia Corporation and/or its subsidiary(-ies) I traced this back to QPdfEnginePrivate::writeInfo(). Looking in Qt 5 I see the same thing only the copyright holder has changed to Digia: (C) 2012 Digia Plc and/or its subsidiary(-ies) I am not a lawyer, but this seems to imply that Nokia/Digia is asserting a copyright claim to content I created. Now preceding the copyright notice is the Qt version (from QT_VERSION_STR), which got me thinking that perhaps a trademark claim was trying to be asserted on the name "Qt" but was incorrectly executed as a copyright claim. Can someone comment on the intent of the copyright notice in QPdfEnginePrivate::writeInfo()? I think it either needs to be removed or changed to a trademark notice. Regards, Jeff Kehres - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ 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 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. --
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] configure failure on Mac
On Oct 3, 2013, at 4:09 AM, Sorvig Morten wrote: > Do you happen to have xcb and/or pkgconfig installed via Macports? I can > reproduce the build error in that case. Ah, yep you're right -- I do. > A quick workaround is to configure with "-no-pkg-config". That did it. > This should arguably be the default when building for OS X: I'd vote for that. Thanks -- Glen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Nokia/Digia copyright in PDF produced by QPrinter
I'm using QPrinter in Qt 4.8 to produce a PDF document. In the metadata of the generated file (specifically the producer field) there is a Nokia copyright: (C) 2011 Nokia Corporation and/or its subsidiary(-ies) I traced this back to QPdfEnginePrivate::writeInfo(). Looking in Qt 5 I see the same thing only the copyright holder has changed to Digia: (C) 2012 Digia Plc and/or its subsidiary(-ies) I am not a lawyer, but this seems to imply that Nokia/Digia is asserting a copyright claim to content I created. Now preceding the copyright notice is the Qt version (from QT_VERSION_STR), which got me thinking that perhaps a trademark claim was trying to be asserted on the name "Qt" but was incorrectly executed as a copyright claim. Can someone comment on the intent of the copyright notice in QPdfEnginePrivate::writeInfo()? I think it either needs to be removed or changed to a trademark notice. Regards, Jeff Kehres - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] configure failure on Mac
On Oct 3, 2013, at 2:30 PM, Jørgen Lind wrote: >> > > But if you happen to have pkg-config in your path, why should we then > not use it. The user has "one way or the other" added it to the path, > so why shouldn't it be used. > > I think the interesting question is why configure fails when you have > a version of xcb that is missing some headers. Maybe a warning would > be enough? You may not know you have pkg-config - it got installed as a dependency of something else. I think having various utilities installed via Macports or Homebrew is quite common, but that does not mean you neccesarily want your Mac (or iOS) apps to use those libraries. I've seen the same thing happen with ICU: Qt pulls in the Macports version and then fails to compile against it. We could fix all cases one by one but that could turn out to be a long journey. Instead, let's make the default OS X build only use public API from the official SDKs. That way we get a minimal deployment that can be deployed to the app stores. If you want to use pkg-config you can then either use a different mkspec (for example when cross-compiling), or pass "-pkg-config" to configure line. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [IMPORTANT] Re: QtBase_stable in CI broken down
we have canceled all integrations, and reset all staging branches and pending changes, so we hope everything is back to normal (for the time being ...). before you stage, rebase your changes and see whether they don't disappear from the stack of pushable changes - some changes got integrated without this becoming visible in gerrit! gerrit will allow you to stage those changes and will create duplicated empty commits. please abandon these changes instead and tell me about them so i can fix the state. On Thu, Oct 03, 2013 at 09:19:44AM +, Sarajärvi Tony wrote: > We have a problem in Gerrit releated to QtBase_stable. We know what has gone > wrong, but we don't know how that's possible, nor how to fix it properly. > Needless to say, investigation is ongoing. > > Thank you for your patience. > > -Tony > > > Tony Sarajärvi > > CI Tech Lead > > Digia, Qt > > ___ > 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] configure failure on Mac
On 3 October 2013 11:09, Sorvig Morten wrote: > On Oct 3, 2013, at 3:10 AM, Glen Mabey > wrote: > >> >> I'm on the dev branch but experienced this issue before the 5.2 and 5.3 >> branches split. >> >> macbookpro:qtbase$ ./configure -prefix ~/src/take2/install >> >> >> >> Running configuration tests... >> The test for linking against libxcb and support libraries failed! >> You might need to install dependency packages, or pass -qt-xcb. >> See src/plugins/platforms/xcb/README. >> >> >> Which seems to me like it's performing X11 checks on the wrong platform. >> >> I can file a bug if I'm really not missing something obvious … > > > Do you happen to have xcb and/or pkgconfig installed via Macports? I can > reproduce the build error in that case. > > A quick workaround is to configure with "-no-pkg-config". This should > arguably be the default when building for OS X: But if you happen to have pkg-config in your path, why should we then not use it. The user has "one way or the other" added it to the path, so why shouldn't it be used. I think the interesting question is why configure fails when you have a version of xcb that is missing some headers. Maybe a warning would be enough? Jørgen ___ 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 > 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?
(sorry for jumping in the middle of the discussion) >Quoting style guides that apply for applications can by definition not >contain reasoning for library writers. Apps live in their own little >dream world and can play with the compiler flags anyway they wish. They >only target one App, after all, and if they switch off exceptions or >RTTI, no user user will care. Yes, LLVM also provides libraries. But >they're narrowly-focused and, what's more important, they're toolkits, >not frameworks. Meaning they don't force a particular structure on your >program. Yes, there are probably checkers that use the LLVM libraries as >a framework, but now we're really leaving the realm of general-purpose >libraries and are comparing apples and oranges. > >My pov on this whole discussion is this: > >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. 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'm not so sure if I follow your logic here, but Qt does not necessarily need to just blindly provide everything the users might want. In this case I think that the benefits Qt will get out of having two separate code paths for supporting and not supporting exceptions are not enough to justify having those two code paths in the first place (and I think a large part of the audience leans that way too). >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. > Throwing exceptions without having a way to safely reenter the event loop is not very desirable. It is the equivalent of being able to change the wheels in your car while driving it but not being able to steer the car while doing it. In my book that is a big no-no. If exception support is deemed necessary then that should be solved before the discussion continues. >At the same time, there should be an easy way to build Qt with exception >support disabled, for those apps that don't want to handle their errors. > >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? > If you look at things under that light, they are not that different. But there is the underlying difference that exceptions will produce out of order code paths that might produce subtle problems that might take years to discover and fix. Debug symbols are easy, you either have them or not. Threads are even easier, you can build a library with thread support and the same code will work without modifications if you remove thread support (well, mostly). Exceptions on the other hand will require us to be able to assure that we can contain them safely _OR_ that we tell users that they need to wait for unexpected exceptions. The problem with exceptions is that there is no middle ground, as with for instance libc signals. You either start throwing them and catching them or you don't. This proposal is just to make the latter the default case, which makes sense in my view.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtBase_stable in CI broken down
We have a problem in Gerrit releated to QtBase_stable. We know what has gone wrong, but we don't know how that's possible, nor how to fix it properly. Needless to say, investigation is ongoing. Thank you for your patience. -Tony Tony Sarajärvi CI Tech Lead Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
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] configure failure on Mac
On Oct 3, 2013, at 3:10 AM, Glen Mabey wrote: > > I'm on the dev branch but experienced this issue before the 5.2 and 5.3 > branches split. > > macbookpro:qtbase$ ./configure -prefix ~/src/take2/install > > > > Running configuration tests... > The test for linking against libxcb and support libraries failed! > You might need to install dependency packages, or pass -qt-xcb. > See src/plugins/platforms/xcb/README. > > > Which seems to me like it's performing X11 checks on the wrong platform. > > I can file a bug if I'm really not missing something obvious … Do you happen to have xcb and/or pkgconfig installed via Macports? I can reproduce the build error in that case. A quick workaround is to configure with "-no-pkg-config". This should arguably be the default when building for OS X: https://codereview.qt-project.org/#change,67213 Morten ___ 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?
On 2013-10-02 20:39, André Pönitz wrote: [...] > > > tp://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." Quoting style guides that apply for applications can by definition not contain reasoning for library writers. Apps live in their own little dream world and can play with the compiler flags anyway they wish. They only target one App, after all, and if they switch off exceptions or RTTI, no user user will care. Yes, LLVM also provides libraries. But they're narrowly-focused and, what's more important, they're toolkits, not frameworks. Meaning they don't force a particular structure on your program. Yes, there are probably checkers that use the LLVM libraries as a framework, but now we're really leaving the realm of general-purpose libraries and are comparing apples and oranges. My pov on this whole discussion is this: 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. 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. 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. At the same time, there should be an easy way to build Qt with exception support disabled, for those apps that don't want to handle their errors. 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? (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). Other than that I can only +1 what Olivier already said about testing, incl. offering help. > 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 > > > > > ://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". I strongly oppose use criticism of C++98 exception specifications to argue against exception
[Development] DNS resolver docs for Linux/OSX
Hi All, Is there any good documentation on the DNS resolver library (in Linux). I've mostly been referring to manpages of resolver functions (res_init et all) which gives an overview of the main functions. However, I wanted to know more about the main "struct __res_state" used in these functions. Google hasn't thrown up much. Basically, I wanted to know the usage of 2 of the fields used in this struct - "nssocks[MAXNS]" and "nsmap[MAXNS]". What values are these supposed to hold? Thanks, -mandeep ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
