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 support. That is such a fundamental logic error, I don't even know how to rebuke it politely :) _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development