On Wed, Oct 2, 2013 at 12:39 PM, André Pönitz < andre.poen...@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
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development