* Desire for static reflection (despite the fact that this is against the compilation model)

Really hoping this becomes a reality. Could solve a lot of things. Even the need for Qt's moc compiler ( http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html )

Regarding exceptions... This is anecdotal evidence, but I've made some toy graphics applications that use exceptions, and noticed that weaker PCs would grind down to a halt if a bug caused an exception to be thrown at every frame of gameplay. I didn't figure out why, but I assume something is being totally thrown off. Makes me think games are better off just ignoring errors and just logging/asserting in debug builds instead.

I asked some emscripten people about best practices for exceptions, and the answer was something like "no dude... just... just don't." so it seems like you can't safely assume exceptions are okay universally.

Exceptions should only be used in exceptional situations. Modern (x64) zero-cost exceptions are truly free (so much cheaper than return value checking) as long as no exception is thrown. As soon as an exception is thrown, it becomes a thousandfold more expensive than return checking due to massive icache misses, multiple indirections etc.

Exceptions should only be used in exceptional situations.

Except nobody really uses them like that. Boost is a "great" example here. File exists? Throw! File doesn't exist? Throw! But it's not just Boost, many projects use them like that. Every action can lead to an unexpected exception, followed by a crash/slowdown.

If you can't "defuse" an exception quickly, what's the point? Errors can be thrown with plain functions too. Would be much cheaper/safer as well, plus you'd have access to the call stack.

On a side note, I wish there was some standardized way to access the call stack. It's a solved issue in any half-decent, modern language.

If you are talking about Boost.Filesystem, most functions in Filesystem support either using an error code or throwing an exception, see the third bullet point on http://www.boost.org/doc/libs/1_57_0/libs/filesystem/doc/index.htm

The rules regarding exceptions and RTTI are being relaxed at many companies. Twenty years ago when the rules were being introduced everywhere it was because exception handlers had all kinds of negative properties. Compilers generated a little bit of code in every function call for stack tracking and unwinding, and RTTI required very large tables of data and were slow to process. Since several sub-components of both share the same technology, and since the cost was present even if exceptions were never called and dynamic casts never used, both were typically off by default. Skip to today, 2015, and compilers have advanced. There is a small table of data needed by the executable, but nowhere near as large as two decades ago. Exceptions no longer need every function call to include stack unwinding information, instead there is a lookup cost when they are used -- but games can be written in ways that never trigger c++ exceptions except through what are normally fatal bugs anyway.

Why aren't more console game developers using exceptions then? I'm aware that the "zero-cost" exception handling model increases the executable speed a bit and thrown exceptions are really slow, but surely that is better than locking up the console and forcing the user to reboot the entire system when an error condition occurs? From what I've seen, the typical error handling strategy is basically non-existent. Using asserts and trying to catch all the criticial bugs in debug builds is not an error handling strategy. C++ without exceptions is a broken language as far as I'm concerned.

They aren't used because they used to be bad. And since they didn't used to be used, large swaths of existing code isn't written to handle them. None of that code was written with exception safety in mind (heck, it's still hard to get people to follow proper RAII practices).

Throw exceptions into the mix and you have a recipe for disaster as functions can start exiting in places the code didn't expect, leaking memory, and all sorts of other things. I would imagine that most of the "bugs" people chalk up to the compiler or "broken" exceptions are actually due to not coding in an exception-safe manner.

So until someone is willing to go through an entire code base and make sure exceptions can propagate cleanly - they will probably continue to be unused.

And no one is going to be willing to pay for a coder's time to do that - at least until someone takes their free time to remove all the "if (error-that-never-happens)" code and notices the speedup they get from removing lots of branches. (Or lack thereof)

Exceptions should only be used in exceptional situations. Modern (x64) zero-cost exceptions are truly free (so much cheaper than return value checking) as long as no exception is thrown. As soon as an exception is thrown, it becomes a thousandfold more expensive than return checking due to massive icache misses, multiple indirections etc.

Not everything uses the zero-cost exception model. Namely, emscripten. (

) Furthermore, exceptions (zero-cost or not) depend on RTTI, which is non-ideal.

Not everything uses the zero-cost exception model. Namely, emscripten. (

)

True. x86 (32 bit) compilers on Windows don't do so either AFAIK.

Furthermore, exceptions (zero-cost or not) depend on RTTI, which is non-ideal.

They are both core parts of the language, so switching them off is compiler-dependent anyways, but it used to be possible to switch of RTTI but keep (and use) exceptions on GCC.

EDIT: After having a look at the video, maybe you meant in emscripten?