"Massimiliano Mirra" <list / NOSPAMchromatic-harp.com> wrote in message
news:20020803231558.GA11531 / prism.localnet...
> On Sun, Aug 04, 2002 at 07:56:21AM +0900, Phil Tomson wrote:
> > We started off wanting to do unit testing of our C++ classes so I tried
> > out Swig1.3.13 to wrap our classes.  Let's say you have three classes,
> > we'll call them Line, Polygon and Point and let's say you want to have
> > them live in a namespace called Geo.  You would define an interface file
> > as an input to swig that would looks something like:
> >
> > %module Geo
> > %{
> > #include "Line.h";
> > #include "Polygon.h";
> > #include "Point.h";
> > %}
> > %include "Line.h";
> > %include "Polygon.h";
> > %include "Point.h";
> >
> > //end of Geo.i (probably not completely right, I'm doing from
> > memory)
>
> Wait a minute.  Do you really mean that, after you've written your C++
> classes, you just feed nine lines to Swig and after some crunching you
> have them available in Ruby?  Or are you just simplifying?
>
> Massimiliano

That is not simplifying at all for basic functionality.  Certainly depending
on your C/C++ code and how you want it to act in Ruby could mean you must
learn more advanced SWIG features.

SWIG in the last few months has made great strides with C++.  You used to
have to do lots of tricks to fool it into doing the right thing, but now
some pretty complex C++ features and types are supported out of the box:.
There are also new library functions for automatically translating STL
vectors into Ruby arrays, and more on the way.  SWIG is being _very_
actively developed right now.  It's a great tool with very responsive
developers.

We've been using C++/Ruby exactly how Phil is describing for over a year,
and the progress SWIG has made in that time is astounding.  Lyle Johnson has
made sure that the Ruby module is one of the best/most up-to-date SWIG
modules for supporting new features in the SWIG core.  (We also wrap the C++
classes into Perl and Tcl using SWIG as well... but those bindings are not
as popular with the users of our toolkit despite the size of the knowledge
base in those two languages where I work).

Of course, that doesn't mean there aren't things missing that would be nice
(even if some aren't possible)... i.e., a unified SWIG interface for setting
up callbacks from C++ into the target scripting languages, for example...
support for faking multiple inheritance in Ruby by adding wrappers for
secondary/tertiary ancestors directly into the subclass's Ruby class
methods...

Using SWIG is really quite easy... managing shared libraries that are
dynamically loaded into various versions of perl/ruby/tcl on mutiple
platforms... well that can get really ugly (especially when one of those
platforms is evil HPUX with its horrible, horrible dynamic loader).
Certainly the embedding approach simplifies that aspect, especially if you
statically link Ruby (or whatever scripting language you are using SWIG
for).