On Tue, 06 Jan 2015 18:32:10 -0800 Matt Wette <[email protected]> wrote: > What are the concerns when integrating C++ code into guile? > > I'm guessing interleaved C++ exception handling, but are there others. > > Assuming the C++ code calls no guile code, should all C++ exceptions > be caught at the interface?
Things come in clumps, as there was a thread about this a few days ago. If your question could be re-expressed as "what are the concerns when calling libguile in C++ code", then the rules I follow do indeed mainly relate to exception handling, and are: 1. Don't allow a guile exception to take a C++ object with a non-trivial destructor out of scope. (Compare §18.10/4 of C++11: "A setjmp/longjmp call pair has undefined behavior if replacing the setjmp and longjmp by catch and throw would invoke any non-trivial destructors for any automatic objects.") Bear in mind also that most libguile functions can throw a guile exception, if only an out-of-memory exception, but there are many others - type mismatches and so forth. 2. Don't allow a C++ exception to propagate out of a guile dynwind block, nor out of a function with C language linkage. (Someone has suggested that you could propagate a C++ exception out of a function with C language linkage if the C code has been compiled with gcc using its -fexception language extension, but that still might not get you very far in practice.) 3. If you are passing a user function (via a function pointer) to libguile, give it C language linkage, although gcc and clang are forgiving about this as they use the same calling convention for C functions, C++ non-member functions and C++ static member functions (but the standard does not mandate that). There are other issues to consider if you intend to call libguile in your program in more than one thread. This may, or may not, give you some ideas: http://sourceforge.net/p/cxx-gtk-utils/git/ci/master/tree/c++-gtk-utils/extension.h Chris
