Plan for Exceptions and @nogc?

[Matthias Bentrup via Digitalmars-d]

On Wednesday, 18 February 2015 at 08:13:35 UTC, Ola Fosheim 
Grøstad wrote:
> On Wednesday, 18 February 2015 at 00:54:37 UTC, Chris Williams 
> wrote:
>> I didn't mean it as a solution. As said, I was just looking 
>> for an intro to the topic, so that I (and others) could 
>> meaningfully contribute or at least understand the options. 
>> I'll look up libunwind and, if that has enough info for me to 
>> grok it, create a wiki page on the subject.
>
> It is a horrible solution developed for the Itanium VLIW 
> architecture which is very sensitive to branching. IRRC it 
> basically works by looking at the return address on the stack, 
> then picking up stack frame information in a global table to 
> unwind. It is language agnostic and the language provides a 
> "personality function" to unwind correctly in a language 
> dependent manner...
>
> AFAIK, C++ exceptions are copied from the stack to a special 
> memory region when unwinding to prevent the memory issues D 
> suffers from.
>
> I agree that a fast unwind with stack pointer reset or multiple 
> return paths would be much better, but you need to rewrite the 
> backend to support it. That's the main issue... the "fast path" 
> argument is just a sorry excuse that literally means that 
> exceptions are avoided for common failures in C++. As a result 
> you get APIs that are nonuniform.

Windows SEH maintains a per-thread linked list of exception 
handlers, but the C++ runtime seems to install only one handler 
at the start of every function and resorts to lookup tables if 
there are multiply try{}s in the function.

If you want to avoid lookup tables, you can of course add/remove 
catchers dynamically whenever you enter/leave a try block, that 
would add a small cost to every try, but avoids the (larger) 
table lookup cost on the catch.