Re: Prototype for C++-compatible Guile Exceptions.

[Mark H Weaver]

Taahir Ahmed <address@hidden> writes:

> Currently, the use of libguile functions from C++ is fraught with
> danger.  C++ destructors are not triggered by guile exceptions, and the
> dynwind mechanism is ill-suited for application to C++ data structures
> (in particular, STL structures).

I agree that we need to improve this.  Thanks for stepping forward to
work on it.  I apologize for the long delay.

> This sequence of patches addresses this shortcoming by using hidden C++
> exceptions to perform the stack unwinding when a guile exception is
> thrown, so that the pre-checking demonstrated above is not needed.

Your proposal is not unreasonable, but at the present time I feel rather
strongly that we should keep C++ and its runtime out of core Guile.  For
one thing, the C++ runtime, calling conventions, and exception model are
poorly suited to Scheme, with its more general control flow, proper tail
calls, garbage collection, etc.

Also, especially when we have native code generation, I expect it will
be highly beneficial to have complete control over our runtime, internal
calling conventions, and internal exception handling.  These
considerations argue for us to move in the direction of _fewer_
marriages to external runtime libraries rather than more.

Having said that, of course we must retain good integration with code
written in other languages and runtimes such as C and C++.

In my opinion, the best approach is to *convert* exceptions at the
boundaries between libguile and application code.  This opens the door
for us to integrate nicely not only with C++, but also with other
languages and runtimes.

In general, the approach would be to add language-specific wrappers for
all public libguile API functions.  These would arrange for Guile
exceptions thrown within libguile to be converted into whatever type of
exception or error handling is desired by the caller.

Wrappers would also be needed at the interfaces where libguile calls
back to user code.  These wrappers would do conversion in the other
direction, e.g. by catching C++ exceptions and converting them into
Guile exceptions.

I'm not sure what is the best approach to creating these wrappers, but I
guess it could be done with some combination of the C preprocessor and
snarfing tools that scrape our headers and generate code.  I guess it
will also involve adding an optional C++ library containing code needed
by the wrappers.

I'm okay with adding C++ code within "#ifdef __cplusplus" in our
headers, as long as a C++ compiler is not needed to compile libguile or
its C users.

Do you think that an approach like this would work for you?

    Regards,
      Mark