From octave-maintainers-request at bevo dot che dot wisc dot edu Fri Nov 15 09:27:05 2002
Subject: Re: more on exceptions; new handler
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: octave-maintainers mailing list <octave-maintainers at bevo dot che dot wisc dot edu>
Date: Fri, 15 Nov 2002 09:23:12 -0600

On 15-Nov-2002, Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov> wrote:

| We are at this point very dependent on a standard C++ compiler, so assuming
| exceptions is not going to cost us anything in terms of portability.  

OK.

| To be sure that this is the case, I would like to see your except.cc
| extended to handle all the cases (fortran code, callbacks, dynamic loading)
| so that we can see how well it does (or does not) work on various
| platforms.  I'm too tired to do anything about it tonight though.

I can do that if you think it would be useful.  I've also been adding
these features to Octave itself now, but it would be nice to have a
simpler example.  In the process though, I think I'll just clean up
except.cc to not have a #define for the non-exceptions style.
Otherwise, it is too confusing, and we already know that the other way
works (as best it can).

| BTW, with C++ exceptions I presume the unwind_protect class is now
| different?

Not yet, but it could (and probably should) be.

| Now you can define unwind_protect as a local variable which
| does the unwind operation when it is destructed rather than performing an
| unwind stack walk after a long jump.  At least, you can if C++ guarantees
| that the destructor is called immediately when the variable goes out of
| scope.

It should be, I think.

| Is this any faster than what we have currently?  Or is it just
| different.

I'm not sure whether it would be faster, but I think it might be since
Octave's unwind_protect class uses a string compare to find the frame
boundary.  In any case, it might be a bit cleaner.  We could eliminate
calls to unwind_protect::run() and unwind_protect::run_frame() since
that would be handled automatically by destructors when the objects go
out of scope.

| This leads to another question, which is whether or not it is feasible
| to implement evalin, which allows a function to evaluate a variable in
| the caller's environment.  Not that I particularly need this feature.

Yes, I think we can implement evalin.  I think that was already
possible, even without using C++ exception handling?

jwe