i am not too fimiliar with swig. but it's starting to sound like one of
those things that i must take a look at. your notion of using ruby to
control all your c++ objects sounds mighty powerful to me --like having
the best of both worlds.

yet, it is interesting that this comes up at this moment for i just
finished reading Strategies For Scripting, page 44 of the latest Linux
Magazine issue. It talks about PDB, the Gimps procedural database. that
is a very slick notion in itself. the idea being that the Gimp, as well
as applications setting up to script it, register procedures into this
procedural database, and then they are accessible from ANY scripting
language as if NATIVE! like the article suggested, if this approach were
abstracted away from Gimp to stand on its own, it would be the killer
tool. talk about the dreams of REXX! i already forsee the death of SOAP!

so while i think your swig idea rocks and i say rock it, keep one eye to
the sky, the future bomb is pdb.

~transami



On Sat, 2002-08-03 at 00:35, Phil Tomson wrote:
> I'm working a C++ project for a contract I'm doing.  Originally, the 
> client was thinking that they would like to have a scripting language embedded 
> into the application eventually (and of course I've been advocating Ruby 
> for this and they have been receptive since Ruby is used elsewhere within the 
> organization).  Yesterday I needed to begin to define a configuration file 
> format and the thought of parsing the config file in C++ was not 
> pleasant...
> 
> Then it hit me... we alreay wrap all of our C++ objects with Swig so that 
> we can do unit testing in Ruby using Test::Unit so why not take it a step 
> further and use Ruby to tie together all of our C++ objects.  The idea 
> being that instead of embedding Ruby into our C++ application we'll use 
> Ruby to manipulate the objects defined by C++.  All of the comutationally 
> intensive stuff is already done in those C++ classes so there won't be any 
> performance hit.  We won't define a main() function on the C++ side, we'll 
> just create the shared library from the swig wrappers and instantiate 
> those objects in Ruby.
> 
> So, I wrote the parser for our input file in Ruby in about an hour (it 
> would have taken substantially longer in C++) and started creating the 
> frontend for the C++ part of the application in Ruby.  I actually think 
> this will give us a lot more flexibility when compared to the alternative 
> of embedding Ruby into the C++ app.  And since we were already using Swig 
> for testing purposes it's not costing us any extra time and we don't need 
> to take any extra time to embed Ruby.
> 
> So, why embed when you can swig? (hoping to start a philosophical 
> discussion :-).
> 
> Phil
> 
>  
> 
-- 
~transami