Home Original page

Scripting C++ -- 2 -- a more concrete example.

Craig Maloney cmaloney at physics.ucsb.edu
Thu Feb 28 12:17:54 EST 2002 
Thanks to all for the great leads to wrapper generators for 
multi-language projects, but I'm still confused about my initial 
question, so I'll try to be a bit more concrete.

Suppose that I have a class Crystal, and a class Atom.  I'd like to be 
able to do the following:

-----------------
Crystal c;
...
Atom a1;
Atom a2;
...

c.addAtom(a1);
c.addAtom(a2);
...
c.computeEnergy();
---------------------

Atom is a simple enough data structure that default copy works.

Now here comes the concrete question.  If I want to use this class 
library from a scripting language (e.g. Python) what are the pros and 
cons of using wrapper code (e.g. Boost.Python or SILOON from lanl) vs CORBA.

To me the main differences are:

1) Interface generation.
If I use CORBA, I would have to write IDL interfaces on top of the 
library, since there is no reverse mapping from C++ as there is in java. 
  It seems contrary to the spirit to write the IDL *after* I've written 
the class library -- indicating a lack of regard to issues of 
distributedness in designing the class library. (see my comment at the end)

If I use wrapper generators, it seems like there is a chance (e.g. using 
SILOON/PDT or BOOST/PDT) that it would be possible to have the wrapper 
code automatically generated.

This is a major boon as I would not have to convert 
std::valarray<double> to sequence<double> or whatever monkeying I would 
have to do.  I can imaging this getting pretty hairy to the point of 
unworkable.

2) Marshalling and Objects-by-value.
When the "Crystal" computes its energy it should *NOT* have to marshall 
calls to get at the atom data structures.  This is an operation that 
will be repeated about 2.85 bijillllion times.  In CORBA, this is no 
problem -- I would either have Crystal::addAtom take a valuetype (atoms 
are easy enough to serialize), or I would use some "co-location" trick 
so that the ORB knows that the atom *really* lives in the same address 
space as the crystal.  Preferrably the former.

If using a wrapper generator (e.g. SILOON) I don't see a way around the 
marshalling of the call to get at the atom data structure.

Of course, this would be taken care of by a revamp of the design of the 
class library... maybe making the crystal an atom factory that produces 
new atoms in its own address space.  But I would like to avoid thinking 
about multi-language and distribution issues when designing the core of 
the library.  Is this dream just simply self-contradictory?

Thanks all,
Craig
More information about the Python-list mailing list