From: vor_lord@... Date: 2002-08-04T12:36:50+09:00 Subject: Re: embed or swig? "Massimiliano Mirra" 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).