Re: good tutorial on extending a c++ project with Guile ?

[Chris Vine]

On Mon, 26 Jun 2017 14:45:06 +0200
Samuel Barreto <address@hidden> 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