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' _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
