C++ and stack unwinding/destruction

[David Fang]

Hi all,
        My initial use with guile (1.8 and 1.6) and C++ has been pretty
satisfactory so far -- I think scheme and C++ complement each other very
well, giving the best of both worlds.  However, one serious problem
remains.
        C++ relies heavily on constructor-destructor duality, namely
that objects on the stack are destroyed in reverse order that they are
constructed.  This paradigm is what enables effective resource/memory
management, even in the face of exceptions.  The implementation of guile's
C-style exceptions using setjmp/longjmp, however breaks this universal
law.  Consider:

SCM
my_fun(void) {
my_class c;     // acquires some resources, e.g. memory, mutex
if (...) {
  scm_error_scm(...);   // setjmp exception!
}
// expect c to be destroyed w/ ~my_class() no matter how we leave
return SCM_UNSPECIFIED;
}

In the event of scm_error_scm(), the destructors that *should* be called
in the frame of this function are just skipped.  (Just try printing a
message in the destructor of my_class.)

I dug through some the the archives and found only an inconclusive thread
on "Guile & C++" (ca. 1998-99).

So that brings me to the questions:
Are guile/C++ users and developers aware of this flaw?  (wake-up call!)
Are there plans to fix this?

If I were to go about fixing this, I would consider an option to build
guile/libguile C++-mode replacing the setjmp/longjmp business with
first-class C++ exceptions (throw/catch).  I'm eyeing error.c and throw.c
as places to consider making the initial surgical edits.

However, to make this unintrusive to pure C users, I'd propose an option
such as --enable-cxx to build the C++-safe variant of guile/libguile
(maybe named differently, libguilexx.{a,so,dylib}).


Side note, I'm developing a template library to simplify conversions
between statically-typed STL containers and SCM types.  Has this already
been done, or is there any interest in the community?


Fang



David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
        -- (2400 baud? Netscape 3.0?? lynx??? No problem!)