Ruby C/C++ Interface

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.

···

On 8/23/06, kandlinger@gmx.de <kandlinger@gmx.de> wrote:

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 ?

For an example of this, feel free to look at the source code for the
EventMachine library. The main library was written in C++ and not designed
for Ruby. There is a small wrapper of pure C calls above the C++-based
functionality, and the C wrapper is also not designed for Ruby. And then
there is a standard Ruby extension which only massages data to and from
Ruby-land and calls functions in the C wrapper, which it accesses only by
#including a small header file. We had originally tried dlopen and SWIG and
they were very painful. This approach has been fine.

···

On 8/23/06, kandlinger@gmx.de <kandlinger@gmx.de> wrote:

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 ?

I would say this, from a Java perspective: accessing existing C/C++ code or
writing C/C++ extensions for Ruby is quite a bit easier than writing similar
code for Java using JNI. That said, JNI protects your Java application a bit
better from external bugs, though you can still crash it nicely.

···

On 8/23/06, kandlinger@gmx.de <kandlinger@gmx.de> wrote:

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 ?

--
Contribute to RubySpec! @ Welcome to headius.com
Charles Oliver Nutter @ headius.blogspot.com
Ruby User @ ruby.mn
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com

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 ?

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/

···

On 8/23/06, Dido Sevilla <dido.sevilla@gmail.com> wrote:

On 8/23/06, kandlinger@gmx.de <kandlinger@gmx.de> wrote:
> 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.

Dido Sevilla wrote:

···

On 8/23/06, kandlinger@gmx.de <kandlinger@gmx.de> wrote:
> 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.

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.

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).

···

On 8/23/06, kandlinger@gmx.de <kandlinger@gmx.de> wrote:

Jan Svitok wrote:

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

Jan Svitok wrote:

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/

> 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.

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.

···

On 8/23/06, Dido Sevilla <dido.sevilla@gmail.com> wrote:

On 8/23/06, kandlinger@gmx.de <kandlinger@gmx.de> wrote:

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

···

On 8/23/06, ryan.raaum@gmail.com <ryan.raaum@gmail.com> wrote:

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.

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

Patrick Hurley wrote:

> 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?

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.

···

On 8/23/06, ryan.raaum@gmail.com <ryan.raaum@gmail.com> wrote:

pth

Patrick Hurley wrote:
> > 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?

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.

···

ryan.raaum@gmail.com wrote:

> On 8/23/06, ryan.raaum@gmail.com <ryan.raaum@gmail.com> wrote:

>
> pth

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

···

On 8/23/06, ryan.raaum@gmail.com <ryan.raaum@gmail.com> wrote:

Patrick Hurley wrote:
> On 8/23/06, ryan.raaum@gmail.com <ryan.raaum@gmail.com> wrote:
> > 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?

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.

>
> pth

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.

···

On 8/23/06, ryan.raaum@gmail.com <ryan.raaum@gmail.com> wrote:

ryan.raaum@gmail.com wrote:
> Patrick Hurley wrote:
> > On 8/23/06, ryan.raaum@gmail.com <ryan.raaum@gmail.com> wrote:
> > > 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?
>
> 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.

Patrick Hurley wrote:

>
> Patrick Hurley wrote:
> > > 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?
>
> 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.
>
> >
> > pth
>

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.

···

On 8/23/06, ryan.raaum@gmail.com <ryan.raaum@gmail.com> wrote:
> > On 8/23/06, ryan.raaum@gmail.com <ryan.raaum@gmail.com> wrote:

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

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

···

On 8/23/06, Jan Svitok <jan.svitok@gmail.com> wrote:

On 8/23/06, ryan.raaum@gmail.com <ryan.raaum@gmail.com> wrote:
>
> ryan.raaum@gmail.com wrote:
> > Patrick Hurley wrote:
> > > On 8/23/06, ryan.raaum@gmail.com <ryan.raaum@gmail.com> wrote:
> > > > 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?
> >
> > 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.

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.

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)

···

--
Posted via http://www.ruby-forum.com/.

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

···

On 8/23/06, ryan.raaum@gmail.com <ryan.raaum@gmail.com> wrote:

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.