On Mon, 26 Jun 2017 14:45:06 +0200 Samuel Barreto <[email protected]> wrote: > Hi everyone, > > I want to create a Guile extension to a big C++-based project called > Bio++ (dedicated to bioinformatics and computational biology). > > However I failed to find a good and simple example on how to extend a > C++ program with Guile. My idea was to create a shared library that > can be called from Guile and embedded in a module. I followed > instructions on the Guile reference manual but all of them are > related to C, not C++. I then looked at the source code of LilyPond > and OpenCog but was not able to extract signal from software > idiosyncratic noise. > > So can anyone point me to a good example or a simple tutorial on how > to extend C++ with Guile ? I think the main confusion point to me is > the compilation danse between g++ and gcc.
Using guile with C++ is pretty much the same as using it with C except that there is a problem: exceptions. guile exceptions are in effect implemented using setjmp/longjmp or its cognates. C++ exceptions are not. This means that guile exceptions do not take account of the fact that C++ objects in local scope may have user-provided (non-trivial) destructors - if the scope of such objects is jumped out of, there is undefined behaviour. Furthermore C++ exception unwinding does not take account of guile dynamic extents. This means you have to follow two rules: (i) you should not allow a guile exception arising from calls to libguile made by C++ to exit a C++ scope in which there is a local (auto) C++ object which is not trivially destructible; (ii) no C++ exception should transit out of a scm_dynwind_begin()/ scm_dynwind_end() pair. Note also that C and C++ code should not store SCM objects (which are pointers to guile scheme objects) in memory blocks allocated by malloc() or the new expression, or they will not be seen by the garbage collector used by libguile (which is the gc library) and therefore may be prematurely deallocated. To keep such items alive in custom allocators, SCM variables should be kept as local variables or parameter names in functions (and so stored on the stack or in registers, where they will be seen by the garbage collector), or in memory allocated with scm_gc_malloc(), where they will also be seen by the garbage collector. You can see one approach to this at http://cxx-gtk-utils.sourceforge.net/2.2/namespaceCgu_1_1Extension.html . Chris
