[Development] Disabling exception support in QtCore?

[Charley Bay]

On Wed, Oct 2, 2013 at 12:39 PM, André Pönitz <
andre.poenitz at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131002/3153c764/attachment.html>