[Development] Disabling exception support in QtCore?

Marc Mutz marc.mutz at kdab.com
Thu Oct 3 09:43:18 CEST 2013


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 :)




More information about the Development mailing list