From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan Wedekind Newsgroups: gmane.lisp.guile.user Subject: Re: C++ Foreign Function Interface Date: Mon, 14 Mar 2016 21:12:59 +0000 (GMT) Message-ID: References: <87a8m6nqm4.fsf@gmail.com> <87vb4s4vma.fsf@gmail.com> <42BB375A-66DE-4517-A2C4-4550867C4425@telia.com> <87k2l559mf.fsf@gmail.com> <20160314192216.16464ddd@bother.homenet> Reply-To: Jan Wedekind NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-47062246-1457989982=:15996" X-Trace: ger.gmane.org 1457990008 25029 80.91.229.3 (14 Mar 2016 21:13:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Mar 2016 21:13:28 +0000 (UTC) Cc: guile-user@gnu.org To: Chris Vine Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Mar 14 22:13:20 2016 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1afZnj-0001lK-Rq for guile-user@m.gmane.org; Mon, 14 Mar 2016 22:13:19 +0100 Original-Received: from localhost ([::1]:44113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afZnj-0001eR-3d for guile-user@m.gmane.org; Mon, 14 Mar 2016 17:13:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37159) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afZnY-0001dL-Pc for guile-user@gnu.org; Mon, 14 Mar 2016 17:13:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afZnV-0001DD-Iz for guile-user@gnu.org; Mon, 14 Mar 2016 17:13:08 -0400 Original-Received: from basicbox4.server-home.net ([195.137.212.26]:41978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afZnV-0001Ci-9r for guile-user@gnu.org; Mon, 14 Mar 2016 17:13:05 -0400 Original-Received: from wedemob.default (unknown [95.150.201.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by basicbox4.server-home.net (Postfix) with ESMTPSA id 635DE153066C; Mon, 14 Mar 2016 22:13:01 +0100 (CET) X-X-Sender: jan@wedemob In-Reply-To: <20160314192216.16464ddd@bother.homenet> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 195.137.212.26 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:12486 Archived-At: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-47062246-1457989982=:15996 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On Mon, 14 Mar 2016, Chris Vine wrote: > On Mon, 14 Mar 2016 21:34:24 +0530 > Arun Isaac wrote: >> Hans =C3=85berg writes: >> >>> When calling C++ from C, you can=E2=80=99t pass a C++ exception throu= gh the >>> C code. So in my example code, there are conversions between C++ and >>> Guile exceptions. >> >> Yeah, this was the discussion in the other thread you linked >> to. Unfortunately, I don't know anything about C++ exceptions, and >> hence didn't understand what your code was doing. Can any of this be >> integrated into guile itself, so that C++ FFI will be easier for the >> end programmer? > > I am not a guile developer but I doubt (as a C++ programmer) that that > is worth the effort. If you are calling into a C++ library from any C > code then you need to consider what exceptions the library might > throw. Your 'extern "C"' interface then needs to catch these > exceptions and turn them into something else. That might mean > providing a return value indicating an error condition, or if you are > programming in guile mode with libguile at that point might mean > throwing a guile exception. You can probably ignore std::bad_alloc. > On most modern systems that exception will not be thrown (you will just > thrash), and when you are out of memory there is nothing you can do to > recover anyway as the kernel will take over. The overall point is that > you need to ensure that, if you are in guile mode, any C++ exceptions > are handled locally and do not escape out of a guile dynamic extent nor > out of a function with C calling convention. > > You also need to be aware of the converse, namely that if you throw a > guile exception out of C++ code, there are no C++ objects with > non-trivial destructors in scope when the guile exception is thrown, or > you will get undefined behaviour: most probably the destructors of the > C++ objects will not be called. A guile exception is basically a long > jump up the stack. But that is almost certainly not an issue if all > you are doing is calling into a C++ library when in guile mode. It > will be an issue if you are yourself constructing your own C++ objects > when in guile mode. > > In most cases this is pretty easy to accomplish once you get the hang > of it. > > Chris > It might be worth having a look at Christian Schafmeister's CLASP [1,2].=20 There is no standard C++ binary ABI (application binary interface). CLASP= =20 basically is a Lisp with an interface to LLVM C++ binaries. I think in general it will be necessary to parse the C++ headers in order= =20 to interface with the C++ binaries (e.g. virtual method tables, member=20 variables, functions declared in header files). Jan [1] https://github.com/drmeister/clasp [2] https://www.youtube.com/watch?v=3D8X69_42Mj-g --8323329-47062246-1457989982=:15996--