Discussion:
FFI library for ruby C/C++ extensions
Josef Reidinger
2014-01-08 16:15:23 UTC
Permalink
Hi,
I would like to point to interesting library for C extension to ruby.
short:

just look at https://github.com/ffi/ffi how you can do quick and easy C
bindings from ruby code ( so no C code needed ). For C++ you should
look at https://github.com/jasonroelofs/rbplusplus

long story:

We discussing on lunch about various quality of C bindings ( hating
perl C bindings :) ) and we remembered that duncan do something with
it, but I cannot remember more details. Martin think that FFI is about
making C api better but need to write in C. So I look into it how it
works and are quite surprised that
1) you write it in ruby
2) is really straight forward
3) doesn't work well C++ ( let me fix it if I understand it wrong ).
But I found that exists also library for it rb++
https://github.com/jasonroelofs/rbplusplus

I think it is much better option then generating interface with Swig
which is quite buggy and limited, especially for complex C++ and resul
is not nice ( often object hierarchy is broken ).

Josef
Duncan Mac-Vicar P.
2014-01-10 09:17:24 UTC
Permalink
Post by Josef Reidinger
We discussing on lunch about various quality of C bindings ( hating
perl C bindings :) ) and we remembered that duncan do something with
it, but I cannot remember more details. Martin think that FFI is about
making C api better but need to write in C. So I look into it how it
works and are quite surprised that
I was maintaining some rpm bindings that were dated from ruby 1.6 times.
The C code was painful to work with, so I rewrote the whole thing in
pure ruby using ffi.

https://github.com/dmacvicar/ruby-rpm-ffi

The API is mostly compatible, but it does not support install operations
yet, and it targets rpm 4.9 only.
Post by Josef Reidinger
1) you write it in ruby
Yes.
Post by Josef Reidinger
2) is really straight forward
Yes. But you have to be careful, there are some tradeoffs
* if the library API changes your extension will not stop compiling. You
have to have good testcases.
* Some libs are annoying when they use macros in headers, and you can't
access those.
* You have to be more careful if you want to support multiple target
libraries. In a C extension it is more straightforward with #ifdef and
version macros/defines. In ruby is the same but you have less
information at your disposal.
* I am not sure if ffi is supported on all architectures. Check for
s390x and others.
Post by Josef Reidinger
3) doesn't work well C++ ( let me fix it if I understand it wrong ).
The problem is the ABI and name mangling. Even if it worked, you would
be able to call functions, so it would not be an automatic mapping to
the classes.

rbplusplus is a different approach. They use gcc xml output to have the
class metadata, and then convert that to C++ code, using a library call
rice that wraps the MRI C API in C++. You still need to generate C++ in
order to call C++ code or create a small C library that exposes a plain
C api for the C++ API and then call that from FFI.

Or you can implement the mangling for gcc4 and call C++ directly...
--
Duncan Mac-Vicar P. - http://www.suse.com/

SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
--
To unsubscribe, e-mail: opensuse-ruby+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-ruby+owner-***@public.gmane.org
Duncan Mac-Vicar P.
2014-01-10 09:48:35 UTC
Permalink
Post by Duncan Mac-Vicar P.
Or you can implement the mangling for gcc4 and call C++ directly...
BTW, this guy already did a bit of it:

http://rubydoc.info/github/nasser/zajal/FFI/Cpp

Loading...