Re: concerns when integrating C++ code into guile?
On Jan 7, 2015, at 2:09 AM, Hans Aberg wrote: >> On 7 Jan 2015, at 03:32, Matt Wette 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?
> On 7 Jan 2015, at 03:32, Matt Wette 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?
> On 7 Jan 2015, at 14:52, Matt Wette 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
#include
char str[30];
extern "C" char* hi() {
std::string s("Hello world!\n");
strcpy(str, s.c_str());
return str;
}
/* main.c */
#include
extern char* hi();
int main() {
char* p = hi();
printf(p);
return 0;
}
Re: concerns when integrating C++ code into guile?
On Tue, 06 Jan 2015 18:32:10 -0800 Matt Wette 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?
> On 7 Jan 2015, at 03:32, Matt Wette 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?
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?
> On 7 Jan 2015, at 21:24, Ludovic Courtès 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?
On Wed, 7 Jan 2015 23:15:07 +0100 Hans Aberg wrote: > > > On 7 Jan 2015, at 21:24, Ludovic Courtès 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?
On Jan 7, 2015, at 6:45 AM, Hans Aberg wrote: > >> On 7 Jan 2015, at 14:52, Matt Wette 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).
