Ruby C/C++ Interface

[kandlinger]

Hello, I am currently developing a webshop which uses a c/c++ shared
object/dynamic link library for some functions. Currently I am
evaluating which technology I should use. As I've got a completely
free choice I was thinking of Java Server Faces or Ruby on Rails. I
never used Ruby on Rails before, so my question is: How big is the
support of Ruby to access a c/c++ shared object/dynamic link library of
which i only got a c/c++ header file ?

 

[Dido Sevilla]

Hello, I am currently developing a webshop which uses a c/c++ shared
object/dynamic link library for some functions. Currently I am
evaluating which technology I should use. As I've got a completely
free choice I was thinking of Java Server Faces or Ruby on Rails. I
never used Ruby on Rails before, so my question is: How big is the
support of Ruby to access a c/c++ shared object/dynamic link library of
which i only got a c/c++ header file ?

Actually, it's incredibly easy to write C extensions for Ruby,
compared to many other languages. The file README.EXT in the Ruby
source distribution explains how this can be done, and compared to
languages such as Perl (which uses a small domain-specific language)
and Java (JNI is also messy), it is quite simple. Which is why too
many people don't consider Ruby's general slowness that big a problem;
it is easy enough to write C extensions for speed-critical portions of
the code.

 

[kandlinger]

Actually, it's incredibly easy to write C extensions for Ruby,

Thanks for your help, but the problem in my application is:
1. It is c++ code
2. The c++ code is already written (and not designed for Ruby)

Does this matter or is it still easy to use this in Ruby ?

 

[Dido Sevilla]

Thanks for your help, but the problem in my application is:
1. It is c++ code

It doesn't matter. C++ code can be used within a Ruby extension.

2. The c++ code is already written (and not designed for Ruby)

Doesn't matter either. There are literally hundreds of extension
libraries around there, some of which interface with C++ code that was
never designed with Ruby in mind (e.g. the Fox GUI toolkit, and the
FXRuby extension).

 

[Leslie Viljoen]

It's easy to use C++ code in Ruby extensions, but you still need to
know some C++ and you should look out for some gotchas.

You may want to look at some past posts about this:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/100255

Google for "ruby c++ extensions" to get an idea of what you are up
against - it seems that C++ is a bit harder than straight C.

Les

 

[Jan Svitok]

You may also try SWIG, that will generate the extension for you from
your header file (sometimes it needs little tweaking).

http://www.swig.org/

 

[ryan.raaum]

Actually, it's incredibly easy to write C extensions for Ruby,
compared to many other languages. The file README.EXT in the Ruby
source distribution explains how this can be done, and compared to
languages such as Perl (which uses a small domain-specific language)
and Java (JNI is also messy), it is quite simple. Which is why too
many people don't consider Ruby's general slowness that big a problem;
it is easy enough to write C extensions for speed-critical portions of
the code.

Also, it is important to ask if you are on windows or linux/bsd/mac os
x. It is significantly harder to extend ruby on windows than on one of
the unixy systems.

 

[Robin Stocker]

You may also try SWIG, that will generate the extension for you from
your header file (sometimes it needs little tweaking).

http://www.swig.org/

For an example of this, you can take a look at my id3lib-ruby project
[1], where I use the id3lib C++ library from Ruby through bindings
generated with SWIG. It was very easy to create the SWIG interface file
and it works perfectly.

[1] http://rubyforge.org/projects/id3lib-ruby

 

[M. Edward (Ed) Borasky]

You may also try SWIG, that will generate the extension for you from
your header file (sometimes it needs little tweaking).

http://www.swig.org/

I'm just now getting to learn SWIG in general and the Ruby interface in
particular. The Ruby/C interfacing is fairly simple, but C++ is a good
bit more complicated. First off, make sure you have the latest
development version of SWIG -- I have swig-1.3.29. The documentation is
all in HTML; they haven't put up a PDF yet. The web site is
http://www.swig.org.

One thing SWIG lets you do is develop code in C/C++, and then make
interface modules that support *all* the scripting languages SWIG
supports! That is, you write one set of C/C++ code and one set of
interface modules, and SWIG builds the wrapper code for all the
scripting languages!. Right now, they support guile, Java, Lua, mono,
Ocaml, Perl, PHP, Python, Ruby, Tcl/Tk and Pike.

 

[Patrick Hurley]

Also, it is important to ask if you are on windows or linux/bsd/mac os
x. It is significantly harder to extend ruby on windows than on one of
the unixy systems.

Not really. It is significantly harder to build libraries designed for
unixy systems under windows than on those unixy systems. But the Ruby
interface to C/C++ is pretty much identical between platforms. Why do
you say it is harder?

pth

 

[ryan.raaum]

Not really. It is significantly harder to build libraries designed for
unixy systems under windows than on those unixy systems. But the Ruby
interface to C/C++ is pretty much identical between platforms. Why do
you say it is harder?

Because ruby is unix focussed. All the core ruby developers are unix
people. The ruby toolchain is a unix-oriented toolchain (see the
recent 100+ message thread about ruby on windows).

To build on windows, one must either build ruby from scratch using
mingw (a topic of some contention and basically a unix toolset for
windows) or have vc6, which is less than readily available if you don't
already have it. Ruby does not build easily in currently available
microsoft tools.

Starting from scratch, on a vanilla unix system, anyone with reasonable
unix and c knowledge can build ruby and a (minimal) custom extension in
well under an hour.

Starting from scratch, on a vanilla windows system, I would be amazed
if a windows guru could build ruby and a custom extension in under a
full working day.

 

[ryan.raaum]

Because ruby is unix focussed. All the core ruby developers are unix
people. The ruby toolchain is a unix-oriented toolchain (see the
recent 100+ message thread about ruby on windows).

To build on windows, one must either build ruby from scratch using
mingw (a topic of some contention and basically a unix toolset for
windows) or have vc6, which is less than readily available if you don't
already have it. Ruby does not build easily in currently available
microsoft tools.

Starting from scratch, on a vanilla unix system, anyone with reasonable
unix and c knowledge can build ruby and a (minimal) custom extension in
well under an hour.

Starting from scratch, on a vanilla windows system, I would be amazed
if a windows guru could build ruby and a custom extension in under a
full working day.

Qualifying my own post. Using mingw - slightly longer than on unix
allowing for the time needed to install mingw. Using microsoft tools -
much more difficult.

 

[Jan Svitok]

Qualifying my own post. Using mingw - slightly longer than on unix
allowing for the time needed to install mingw. Using microsoft tools -
much more difficult.

For us works compiling with VC7 (2003) and even with VC8 (2005),
although I have to copy those manifests andd runtime dlls along with
extention dll. I know it isn't safe, however we do it for more than a
year and without crashes. So it's possible, but YMMV.
I wouldn't recommend it for production use without consulting with
those who know what are the problematic cases.

To compile under VC8 I had to comment out the compiler check in
config.h since one-click 1.8.4-20.

J.

 

[Leslie Viljoen]

For us works compiling with VC7 (2003) and even with VC8 (2005),
although I have to copy those manifests andd runtime dlls along with
extention dll. I know it isn't safe, however we do it for more than a
year and without crashes. So it's possible, but YMMV.
I wouldn't recommend it for production use without consulting with
those who know what are the problematic cases.

To compile under VC8 I had to comment out the compiler check in
config.h since one-click 1.8.4-20.

In passing: VC6 is quite old now, can Microsoft not be persuaded to
give it away free? I'd be happy to put my CD up for download if it
were legal.

Les

 

[Patrick Hurley]

Because ruby is unix focussed. All the core ruby developers are unix
people. The ruby toolchain is a unix-oriented toolchain (see the
recent 100+ message thread about ruby on windows).

To build on windows, one must either build ruby from scratch using
mingw (a topic of some contention and basically a unix toolset for
windows) or have vc6, which is less than readily available if you don't
already have it. Ruby does not build easily in currently available
microsoft tools.

Starting from scratch, on a vanilla unix system, anyone with reasonable
unix and c knowledge can build ruby and a (minimal) custom extension in
well under an hour.

Starting from scratch, on a vanilla windows system, I would be amazed
if a windows guru could build ruby and a custom extension in under a
full working day.

I won't argue that building Ruby on Windows is somewhat difficult
(well gathering the unixy tool chain for Windows takes some patience
and then the build is pretty easy). But that is not necessary using
the one-click ruby installer and VC6, building C/C++ extensions under
windows from an already compiling library is really quite painless.

To qualify I am a long time C/C++ developer under Windows and Linux.
But I have not encountered any Window's issues with regard to
extension building -- I have been very pleased with how easy it is to
use mkmf under Windows (I plan on trying out the new rake based tool
soon .

Again if you are fighting with a unixy library or your library is
inherently multi-threaded (like the Win32 service interface), then you
will have some issues -- otherwise I find writing C extensions quite
easy in both environments. Of course your mileage may vary.

pth

 

[ryan.raaum]

I won't argue that building Ruby on Windows is somewhat difficult
(well gathering the unixy tool chain for Windows takes some patience
and then the build is pretty easy). But that is not necessary using
the one-click ruby installer and VC6, building C/C++ extensions under
windows from an already compiling library is really quite painless.

The key here is that you have a tool (VC6) which is not generally
available. If one doesn't have this tool, as I don't, then extending
ruby on windows becomes much more challenging.

 

[Marc Heiler]

What also is helpful is if more and more people write
small Tutorials, in total I found only about ~3 really
useful resources about this (aside from the README)

 

[Patrick Hurley]

The key here is that you have a tool (VC6) which is not generally
available. If one doesn't have this tool, as I don't, then extending
ruby on windows becomes much more challenging.

Sorry for being thick headed -- I can see where this would be a
problem. I have many different Win32 C/C++ compilers dating back to a
pile of 5.25" floppies from Zortech, so I never considered this. Just
to check I shot over to ebay -- VC 6 goes for more than Studio 2005 (I
was thinking you would be able to pick it up for next to nothing).

pth

 

[nobu]

Hi,

At Thu, 24 Aug 2006 05:25:55 +0900,
Jan Svitok wrote in [ruby-talk:210200]:

For us works compiling with VC7 (2003) and even with VC8 (2005),
although I have to copy those manifests andd runtime dlls along with
extention dll. I know it isn't safe, however we do it for more than a
year and without crashes. So it's possible, but YMMV.

Recent versions of ruby in CVS embed manifests into DLLs.

To compile under VC8 I had to comment out the compiler check in
config.h since one-click 1.8.4-20.

Then you have to change important definitions at the same time,
or the result files don't work properly.

 

[kandlinger]

Is it possible to develop a ruby application and use a c++ shared
object/dynamic link library on linux and windows without changing the
source code of the ruby application and the c++ shared object/dynamic
link library ? After reading your posts i think this is not as easy.