On Tuesday, 17 February 2015 at 18:40:51 UTC, Matthias Bentrup
wrote:
On Tuesday, 17 February 2015 at 18:30:24 UTC, Jonathan Marler
wrote:
I thought of the same thing but then realized that it would be
impossible to ensure that the catch block wouldn't stomp on
that memory.
The catcher wouldn't stomp any more on the thrower's memory
than a function stomps on the memory of its caller. All the
data of the thrower is safe, because it is above the stack
pointer. The unwinding hasn't been done at that point.
That would work if you didn't have to unwind the stack but
unfortunately you do. The catch block exists in the context of
the function it is written in. That means it assumes the stack
pointer and stack variables are all in the context of it's
defining function. If you executed the catch code when the stack
wasn't unwound, then it wouldn't know where any of the variables
were. Does that make sense? Think about it for a minute. You
proposal suggests that the catch code can be executed no matter
how many child functions have been added to the stack. This is
impossible since the catch code no longer knows where all of it's
stack variables are. Normally it uses an offset to the stack
pointer but now it has been changed. That's why you have to
unwind the stack.
I like that you thought of this idea but you have to follow
through with the details to see whether or not it would work. I
immediately thought of this idea and then realized that it was
impossible. A variation on the idea might work, but the idea as
it is does not. Keep thinking about it though...if nothing else
it will give you a better understanding of the stack. The more
people that are intimate with the inner workings of how these
things work the better.
