[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