...

First, thanks for making this system, and apologies if this isn;t the list for these questions but there appears to be no cffi-users list.

In any case, is there any way to catch the underlying c++ exceptions within a cffi-wrapper? I have developed a C++ library that defines its own exceptions and I would like to trap them and generate an appropriate Lisp Condition. At present deliberately triggering an error (say by passingincorrect parameters to a constructor) gives me back a null pointer.

Btw, do you call out to your library, or you plan to just generate exceptions?

If you do call out, how do you manage it?

I mean, C++ name mangling is hard to keep with, etc...

I call out the library using the cffi foreign-function wrapper. as per the example in the cffi manual. What I ended up doing was making use of SWIG. Swig can both parse C++ and generate CFFI wrappers and so I called it to generate the wrappers. However the existing code in swig has issues so I was forced to hand-edit some of it. It succeeded in handling the name-mangling and so on but its attempted clos wrapper for the C++ had one distinct problem, every method had an extra argument.

It duitifully generated a wrapper for the exception class that I defined in C++ however objects of that instance are not, seemingly, returned by the library at points where they should be. Rather I get (what appears to be) a null pointer instead. I have not yet explored the potential for trapping that pointer as an exception however.

...

Thanks, Collin Lynch.

regards, Samium Gromoff

Felicitations, Collin Lynch.

On Mon, 2007-02-12 at 16:44 +0000, Luís Oliveira wrote:

On 12/02/07, Collin Lynch collinl@cs.pitt.edu wrote:

...

In any case, is there any way to catch the underlying c++ exceptions within a cffi-wrapper? I have developed a C++ library that defines its own exceptions and I would like to trap them and generate an appropriate Lisp Condition. At present deliberately triggering an error (say by passing incorrect parameters to a constructor) gives me back a null pointer.

C++ support would be nice. I don't personally have a need for it, but it would be nice. Patches are welcome! :-)

Personally, I consider C++ so deliberately hostile to interfacing with other languages that I'm not sure I'd even want to be responsible for maintaining code for binding to C++ libraries.

As I understand it, there's not even a platform ABI that one can try to conform to---things like C++ exception handling and name mangling differ not only per-compiler, but vary depending on the version of the compiler being used. (ISTR maybe they did this for amd64? But I don't think there is in the general case...)

Otherwise, you can handle exceptions and other C++ stuff by writing some C glue and calling that with CFFI.

Unfortunately I think this is the most sane way to go at this point.

I suppose another option would be some kind of standard network object protocol like CORBA, but that's a whole separate mess...

James