concerns when integrating C++ code into guile?

concerns when integrating C++ code into guile?

[Matt Wette]

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?

Matt

Re: concerns when integrating C++ code into guile?

[Hans Aberg]

> On 7 Jan 2015, at 03:32, Matt Wette <mwette@alumni.caltech.edu> 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?

In the C/C++ languages proper, C++ can link in C code, but not vice versa, C code can not link in C++ code. So main() must be in C++.

Then one can convert Guile exceptions into C++ exceptions - I do that in [1].

For the other way around, Guile C code calling C++, that is possible in gcc I recall, but unless Guile is recompiled with a special option adding the C++ exception stacks, any exception one tries pass through the Guile code will terminate the program.

Possibly Guile might have a configure option adding those C++ exception stacks.

1. 1. https://secure2.storegate.com/Shares/Home.aspx?ShareID=e195dec2-1c1a-42a1-851e-da47e674d91b

Re: concerns when integrating C++ code into guile?

[Chris Vine]

On Tue, 06 Jan 2015 18:32:10 -0800
Matt Wette <mwette@alumni.caltech.edu> 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

Re: concerns when integrating C++ code into guile?

[Matt Wette]

On Jan 7, 2015, at 2:09 AM, Hans Aberg <haberg-1@telia.com> wrote:
>> On 7 Jan 2015, at 03:32, Matt Wette <mwette@alumni.caltech.edu> 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?
> 
> In the C/C++ languages proper, C++ can link in C code, but not vice versa, C code can not link in C++ code. So main() must be in C++.
> 
> Then one can convert Guile exceptions into C++ exceptions - I do that in [1].
> 
> For the other way around, Guile C code calling C++, that is possible in gcc I recall, but unless Guile is recompiled with a special option adding the C++ exception stacks, any exception one tries pass through the Guile code will terminate the program.
> 
> Possibly Guile might have a configure option adding those C++ exception stacks.
> 
> 1. 1. https://secure2.storegate.com/Shares/Home.aspx?ShareID=e195dec2-1c1a-42a1-851e-da47e674d91b

Python is written in C yet Qt has been integrated in to produce PyQt.   I wonder how that is done.  I will take a look.

Re: concerns when integrating C++ code into guile?

[Hans Aberg]

> On 7 Jan 2015, at 14:52, Matt Wette <mwette@alumni.caltech.edu> wrote:
> 
> Python is written in C yet Qt has been integrated in to produce PyQt.   I wonder how that is done.  I will take a look.

If Python can be compiled as C++, that might be one way.

For proper C, the example below compiles with:
  gcc -lstdc++ main.c test_extern_C.cc -o main
‘gcc' is though 'clang' on OS X 10.10.

---- 
// test_extern_C.cc
#include <string>
#include <cstring>

char str[30];

extern "C" char* hi() {
  std::string s("Hello world!\n");
  strcpy(str, s.c_str());
  return str;
}
----
/* main.c */
#include <stdio.h>

extern char* hi();

int main() {
  char* p = hi();
  printf(p);
  return 0;
}
----

Re: concerns when integrating C++ code into guile?

[Hans Aberg]

> On 7 Jan 2015, at 03:32, Matt Wette <mwette@alumni.caltech.edu> wrote:
> 
> What are the concerns when integrating C++ code into guile?

There is a FAQ about mixing C and C++ here:
  https://isocpp.org/wiki/faq/mixing-c-and-cpp

Re: concerns when integrating C++ code into guile?

[Ludovic Courtès]

If Scheme code calls C++ code that throws an exception, then the stack
will be unwound by libstdc++ and Guile’s ‘dynamic-wind’ handlers and
such will not run.  That’s probably the main difficulty.

Likewise when C++ code calls Scheme code.

TeXmacs and LilyPond both embed Guile in a C++ code base so their
developers probably have more insight into this.  Since these are old
projects, it could be that they don’t use C++ exceptions.

Thanks,
Ludo’.

Re: concerns when integrating C++ code into guile?

[Hans Aberg]

> On 7 Jan 2015, at 21:24, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> If Scheme code calls C++ code that throws an exception, then the stack
> will be unwound by libstdc++ and Guile’s ‘dynamic-wind’ handlers and
> such will not run.  

If one tries to pass a C++ exception through Guile code, it will not catch in C++ code above it, I think.

> That’s probably the main difficulty.

There is a gcc option, but someone said it does not work well, perhaps because any intermediate library and package functions must be recompiled as well.

Another variation might be compile C as C++, i.e. writing Guile in the common C/C++ subset. The Bison skeleton file had that before making a genuine C++ one, though it proved too difficult to maintain, and in addition, one does not get access to C++ features.

> Likewise when C++ code calls Scheme code.

For this, I made a smob and convert Guile errors to a C++ exception. Might be an overhead problem, though.

> TeXmacs and LilyPond both embed Guile in a C++ code base so their
> developers probably have more insight into this.  Since these are old
> projects, it could be that they don’t use C++ exceptions.

C++ exceptions were there since 1993.

Re: concerns when integrating C++ code into guile?

[Chris Vine]

On Wed, 7 Jan 2015 23:15:07 +0100
Hans Aberg <haberg-1@telia.com> wrote:
> 
> > On 7 Jan 2015, at 21:24, Ludovic Courtès <ludo@gnu.org> wrote:
> > 
> > If Scheme code calls C++ code that throws an exception, then the
> > stack will be unwound by libstdc++ and Guile’s ‘dynamic-wind’
> > handlers and such will not run.  
> 
> If one tries to pass a C++ exception through Guile code, it will not
> catch in C++ code above it, I think.
> 
> > That’s probably the main difficulty.
> 
> There is a gcc option, but someone said it does not work well,
> perhaps because any intermediate library and package functions must
> be recompiled as well.

It may or may not work well with respect to unwinding the stack, but
that misses one half of the point. It won't cause dynwind handlers to
run, whatever recompilation you do.

> Another variation might be compile C as C++, i.e. writing Guile in
> the common C/C++ subset. The Bison skeleton file had that before
> making a genuine C++ one, though it proved too difficult to maintain,
> and in addition, one does not get access to C++ features.
> 
> > Likewise when C++ code calls Scheme code.
> 
> For this, I made a smob and convert Guile errors to a C++ exception.
> Might be an overhead problem, though.

It is not just a matter of converting guile exceptions to C++
exceptions.  The issue is that guile propagates its exceptions via long
jumps up the stack, or the equivalent thereof. These will not run
non-trivial destructors for C++ objects taken out of scope by the jump
(and according to the C++ standard, it causes undefined behaviour).
This means that any exception handling has to be localized.

That is not impossible.  There is not that much libguile code needed to
run scheme extension code in a C++ program, if that is what you want to
do.

Chris

Re: concerns when integrating C++ code into guile?

[Matt Wette]

On Jan 7, 2015, at 6:45 AM, Hans Aberg <haberg-1@telia.com> wrote:

> 
>> On 7 Jan 2015, at 14:52, Matt Wette <mwette@alumni.caltech.edu> wrote:
>> 
>> Python is written in C yet Qt has been integrated in to produce PyQt.   I wonder how that is done.  I will take a look.
> 
> If Python can be compiled as C++, that might be one way.

PyQt does not recompile Python in C++ so there must be some way to do it w/o recompiling python (=> guile).

TeXmacs is another application that embeds C++  (Qt) w/ guile (1.8, though).

Re: concerns when integrating C++ code into guile?

[Hans Aberg]

> On 8 Jan 2015, at 01:18, Chris Vine <chris@cvine.freeserve.co.uk> wrote:
> 
> On Wed, 7 Jan 2015 23:15:07 +0100
> Hans Aberg <haberg-1@telia.com> wrote:
>> 
>>> On 7 Jan 2015, at 21:24, Ludovic Courtès <ludo@gnu.org> wrote:
>>> 
>>> If Scheme code calls C++ code that throws an exception, then the
>>> stack will be unwound by libstdc++ and Guile’s ‘dynamic-wind’
>>> handlers and such will not run.  
>> 
>> If one tries to pass a C++ exception through Guile code, it will not
>> catch in C++ code above it, I think.
>> 
>>> That’s probably the main difficulty.
>> 
>> There is a gcc option, but someone said it does not work well,
>> perhaps because any intermediate library and package functions must
>> be recompiled as well.
> 
> It may or may not work well with respect to unwinding the stack, but
> that misses one half of the point. It won't cause dynwind handlers to
> run, whatever recompilation you do.

If you want that, they must be converted somehow.

>> Another variation might be compile C as C++, i.e. writing Guile in
>> the common C/C++ subset. The Bison skeleton file had that before
>> making a genuine C++ one, though it proved too difficult to maintain,
>> and in addition, one does not get access to C++ features.
>> 
>>> Likewise when C++ code calls Scheme code.
>> 
>> For this, I made a smob and convert Guile errors to a C++ exception.
>> Might be an overhead problem, though.
> 
> It is not just a matter of converting guile exceptions to C++
> exceptions.  The issue is that guile propagates its exceptions via long
> jumps up the stack, or the equivalent thereof. These will not run
> non-trivial destructors for C++ objects taken out of scope by the jump
> (and according to the C++ standard, it causes undefined behaviour).

Right.

> This means that any exception handling has to be localized.
> 
> That is not impossible.  There is not that much libguile code needed to
> run scheme extension code in a C++ program, if that is what you want to
> do.

I decided to not pass C++ (non-PODs) objects or exceptions through Guile code. The FAQ I mentioned also deals with how to convert objects to proper C before passing them from C++.

Re: concerns when integrating C++ code into guile?

[Hans Aberg]

> On 8 Jan 2015, at 02:00, Matt Wette <mwette@alumni.caltech.edu> wrote:
> 
> 
> On Jan 7, 2015, at 6:45 AM, Hans Aberg <haberg-1@telia.com> wrote:
> 
>> 
>>> On 7 Jan 2015, at 14:52, Matt Wette <mwette@alumni.caltech.edu> wrote:
>>> 
>>> Python is written in C yet Qt has been integrated in to produce PyQt.   I wonder how that is done.  I will take a look.
>> 
>> If Python can be compiled as C++, that might be one way.
> 
> PyQt does not recompile Python in C++ so there must be some way to do it w/o recompiling python (=> guile).
> 
> TeXmacs is another application that embeds C++  (Qt) w/ guile (1.8, though).

You can pass C++ objects to C code, cf. [1], but longjmp() is incompatible with C++ exceptions. So before passing the C++ object, convert it to POD (plain old data) and catch any exceptions.

1. https://isocpp.org/wiki/faq/mixing-c-and-cpp

Re: concerns when integrating C++ code into guile?

[Matt Wette]

On Jan 7, 2015, at 5:00 PM, Matt Wette <mwette@alumni.caltech.edu> wrote:
> PyQt does not recompile Python in C++ so there must be some way to do it w/o recompiling python (=> guile).

I looked into PyQt a bit.   Only recent versions of Qt have exceptions.  The bulk of the code is exception free.  

Also, PyQt uses a tool called "sip" to generate wrappers for the C++ code to be integrated into Python.

Re: concerns when integrating C++ code into guile?

[Hans Aberg]

> On 9 Jan 2015, at 03:30, Matt Wette <mwette@alumni.caltech.edu> wrote:
> 
> 
> On Jan 7, 2015, at 5:00 PM, Matt Wette <mwette@alumni.caltech.edu> wrote:
>> PyQt does not recompile Python in C++ so there must be some way to do it w/o recompiling python (=> guile).
> 
> I looked into PyQt a bit.   Only recent versions of Qt have exceptions.  The bulk of the code is exception free.

If one is using the standard C++ library, it may throw exceptions.

> Also, PyQt uses a tool called "sip" to generate wrappers for the C++ code to be integrated into Python.

Check if it has a try-catch clause.