Re: [boost] py_cpp and ILU?

From: Ullrich Koethe (koethe_at_[hidden])
Date: 2000-10-11 17:28:42

Hi Prabhu,

I've contributed a little to py_cpp, so I'll try to give some thoughts
on your question.

Prabhu Ramachandran wrote:
> 
>         There are quite a few tools that try to do c++ -> other
> language wrapping (I dont know if this is the right term).  All of
> them seem to share a lot of common features.  As is obvious, most of
> them do very similar things.  Each with its own limitations quirks
> etc.  After a cursory glance, one tool seems to stand out - ILU (Inter
> Language Unification) it even has the right name. :) But it seems 
> to be designed along the lines of CORBA, maybe it is vice versa, 
> whatever...

I think, py_cpp and ILU represent two extremes in a spectrum of
possibilities: ILU is a giant project with extremely broad scope (many
languages, multiple protocols, total unification), while py_cpp is a
small tool that does just one thing elegantly and efficiently.
Accordingly, target applications are different in both cases: one would
use ILU to build a distributed, multi-language object system, but one
would use py_cpp to add scripting to an existing project as quickly as
possible.

I imagine the typical py_cpp user has implemented a (perhaps huge)
system for his particular application area. Now he wishes to add the
capability to use this system interactively (that is, by issuing
commands at a prompt and running scripts). This extension is but a small
(if important) aspect of the whole system, so it should be implemented
by a correspondingly small and simple tool. 

It wouldn't be reasonable to double the size of an entire project (by
adding ILU, for example), just to enhance a small aspect of the
functionality. The burden to programmers and users (installing and
understanding ILU) would be too large in relation to the benefit. Many
projects failed because developers got distracted by huge and beautiful
tools instead of concentrating on their main tasks. In constrast, a
small tool like py_cpp can be easily integrated into the existing
system, so that programmers wouldn't be distracted and users need not
even realize that py_cpp existed.

(The story might look different if ILU-like capabilities were part of
the operating system. Then the general tool would exist anyway, so one
might as well use it without bothering whether it's small or large. But
this requires a degree of standardization that seems to be out of reach
at present.)

> 
> (1) It doesnt make sense for each wrapper creator to hack at her/his
> version of the parser etc. and redo work.  

That's why py_cpp uses the C++ compiler to do most of the work. It needs
some manual assistance - the module file - in order to figure out what
exactly it shall wrap. This isn't as bad as it sounds because 

1. typically one doesn't want to export the whole C++ library, or wants
to export it in slightly modified form (for example, if one wants to
benefit from py_cpp's run-time function dispatch, which is not available
in C++ in the same form) 
2. C++ templates can't be exported as such (no matter which tool you
use), but must be instantiated for particular types.

Of course, additional support for creating the module file would be
highly desirable and is planned.

> But it sure seems to
> make sense to add an abstraction layer between languages. 

Yes, but the smaller the granularity of the wrapped functionality, the
more the complexity of this abstraction layer will hurt performance. A
ridiculous example: imagine your WWW browser would open an ILU
connection for every single pixel of each image - this would be way too
slow. So you will need a thinner abstraction layer for finer granularity
(but probably py_cpp is still to slow to routinely access single
pixels). 

I guess, at present there is no one-size-fits-all solution to your
problem.

Regards
Ulli
-- 
 ________________________________________________________________
|                                                                |
| Ullrich Koethe  Universität Hamburg / University of Hamburg    |
|                 FB Informatik / Dept. of Computer Science      |
|                 AB Kognitive Systeme / Cognitive Systems Group |
|                                                                |
| Phone: [phone]                Vogt-Koelln-Str. 30 |
| Fax:   [phone]                D - 22527 Hamburg   |
| Email: u.koethe_at_[hidden]               Germany             |
|        koethe_at_[hidden]                        |
| WWW:   http://kogs-www.informatik.uni-hamburg.de/~koethe/      |
|________________________________________________________________|