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

Ralf W. Grosse-Kunstleve rwgk at yahoo.com
Fri Mar 1 02:05:07 EST 2002


Craig Maloney <cmaloney at physics.ucsb.edu> wrote in message news:<3C7E6642.2030202 at physics.ucsb.edu>...
> Thanks to all for the great leads to wrapper generators for 
> 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.

Crystals and atoms... that looks familiar to me :-)
See cctbx.sf.net.
This is a C++ library with Python bindings implemented using
Boost.Python.
 
> 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.

I do not know about PDT, it certainly is not currently
integrated with Boost.Python. I.e. you have to write the
wrappers manually. If you do this while developing a library,
the extra coding time is in general negligible compared to
the time it takes to develop the rest. If you want to wrap
a large existing library it can be a bit cumbersome.

> 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?

Does "marshalling" mean converting objects to strings (and vice versa)?
If you use Boost.Python the wrapped C++ objects are never marshalled.
The run-time overhead for crossing the language boundary is very
small. In our applications (higher-level management in Python,
number-crunching in C++) it is hardly ever noticeable.

Ralf



More information about the Python-list mailing list