From: Tom Sawyer <transami@...>
Date: 2002-08-04T20:28:03+09:00
Subject: Re: embed or swig?

i was just reading over a little of the swig docs and HOLY CODING! from
my limited reading it appears that once a swig interface definition is
created you can generate a wrapper for any of the supported scripting
languages. is that true? i imagine there might be a need to make some
minor changes for a large/realistic source. but perhaps not? with this
then it should be rather trivial to wrap a number of libraries for ruby
that already have swig interfaces for python. can anyone confirm this?

if what i gather from the above holds, then a wxWindows binding for ruby
should be pretty sraight foward for anyone with ruby and swig
experience. the same holds true for ParaGUI, and certainly a number of
other apis.

please confirm speculations.

~transami


On Sat, 2002-08-03 at 21:36, vor_lord@hotmail.com wrote:
> "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).
> 
> 
> 
> 
-- 
~transami