[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

C++ and stack unwinding/destruction

From: David Fang
Subject: C++ and stack unwinding/destruction
Date: Fri, 16 Mar 2007 18:24:00 -0500 (EST)

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
        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:

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

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?


David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
        -- (2400 baud? Netscape 3.0?? lynx??? No problem!)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]