From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chris Vine Newsgroups: gmane.lisp.guile.user Subject: Re: C++ Foreign Function Interface Date: Mon, 14 Mar 2016 19:22:16 +0000 Message-ID: <20160314192216.16464ddd@bother.homenet> References: <87a8m6nqm4.fsf@gmail.com> <87vb4s4vma.fsf@gmail.com> <42BB375A-66DE-4517-A2C4-4550867C4425@telia.com> <87k2l559mf.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1457983368 14921 80.91.229.3 (14 Mar 2016 19:22:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Mar 2016 19:22:48 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Mar 14 20:22:39 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 1afY4b-00073l-Ih for guile-user@m.gmane.org; Mon, 14 Mar 2016 20:22:37 +0100 Original-Received: from localhost ([::1]:43580 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afY4b-0003jJ-1V for guile-user@m.gmane.org; Mon, 14 Mar 2016 15:22:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afY4R-0003iv-PA for guile-user@gnu.org; Mon, 14 Mar 2016 15:22:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afY4O-0004jW-EX for guile-user@gnu.org; Mon, 14 Mar 2016 15:22:27 -0400 Original-Received: from smtpout4.wanadoo.co.uk ([80.12.242.68]:23848 helo=smtpout.wanadoo.co.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afY4O-0004jH-53 for guile-user@gnu.org; Mon, 14 Mar 2016 15:22:24 -0400 Original-Received: from bother.homenet ([95.146.111.202]) by mwinf5d60 with ME id VvNG1s00P4N3fKz03vNG2d; Mon, 14 Mar 2016 20:22:20 +0100 X-ME-Helo: bother.homenet X-ME-Date: Mon, 14 Mar 2016 20:22:20 +0100 X-ME-IP: 95.146.111.202 Original-Received: from bother.homenet (localhost [127.0.0.1]) by bother.homenet (Postfix) with ESMTP id 4E29F121347 for ; Mon, 14 Mar 2016 19:22:16 +0000 (GMT) In-Reply-To: <87k2l559mf.fsf@gmail.com> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.30; i686-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.12.242.68 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:12485 Archived-At: On Mon, 14 Mar 2016 21:34:24 +0530 Arun Isaac wrote: > Hans =C3=85berg writes: >=20 > > When calling C++ from C, you can=E2=80=99t pass a C++ exception through= the > > C code. So in my example code, there are conversions between C++ and > > Guile exceptions. =20 >=20 > 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