[C++-SIG] An introduction

[Daryl V. McDaniel]

Hello,

I would like to take this opportunity to introduce myself and briefly describe the project I am currently working on and its relevance to the C++ SIG.

A quick summary of my idealized goals is to achieve seamless, bi-directional, integration between the C++ and Python portions of our product allowing Python to be used as the product's scripting language and as a prototyping language during development.  And, to do this in such a way that my programmers don't have to write special interface code.

Now for some background.  I began programming in 1968 in SOL and Fortran.  LISP, Cobol, and several flavors of assembler followed in the '70s.  Somewhere around 1978 I discovered C and ended up writing a C compiler for the National 16032 processor family sometime around 1983.  In the late '80s I found out about C++ and began using it professionally in 1990.

About 2 months before Python 1.5.2 was released, I began looking for a scripting language to include in our product.  I started the search as a TCL advocate but ended up selecting Python, primarily because of its power and usability by non-programmers.  Python's modularity, embedding, and extension features were also prime decision points.

The product I am responsible for is actually just a small part of our client's complete product.  Its target environment is a distributed system of 1 to 64 nodes acting as a federation of autonomous intelligent agents.  Each node consists of an embedded processor running VxWorks with Python and the C++ application.  There is no disk, no virtual memory, and only a small amount of RAM (32MB).

This is a large, fast track project (which one isn't these days?) that had, in previous generations, been implemented entirely in C++.  The new incarnation is a 90% rewrite due to a vastly different operating environment and system requirements.  We essentially have to deliver about 800,000 new lines of working and tested code by December of this year.

The scripting component of the product must allow non-programmer users (Manufacturing and Service technicians), as well as software-savvy engineers, to write scripts to automate operations, debug systems, or modify operational procedures.  In order to do this, the Python components need access to the low-level C++ implementation.

[So far, I don't think I have said anything really new to anyone, its just background]

I read the section on embedding and extending in the Python documentation as well as the help and hints articles on python.org.  This led me to some of the wrapper packages and eventually to CXX, scxx, SWIG, sip, and the Extension Classes in Zope.  Of all of these, I like CXX best.  SWIG would meet all of my requirements except that the current "stable" version doesn't handle C++ well enough.  I haven't had time to reverse engineer the makefiles so that I could build one of the newer versions -- that is forthcoming.

So, I am currently hoping that between CXX and some documentation I have yet to write, we will be able to write and wrap our C++ code such that the C++ objects are available in Python, as true Python classes, and Pure Python functions and scripts will be available to the C++ code.

This is rapidly becoming more important as we begin prototyping in Python.  It now looks like the code we have to deliver in April will be mostly Python.  The July release to engineering will still be about 80% Python.  So, you can see that Python is taking on a larger role than "just an embedded scripting language".

What I currently believe would be "perfect" would be a merge of SWIG and CXX.  I am not going to be able to do this and won't suggest it be done.  Both SWIG and CXX are fine on their own rights and I don't want to start any wars.

CXX has taught me that I don't know C++, especially templates, as well as I should.  It is providing me with a very practical example to learn from.  It is also allowing my team to "write Python in C++".  The synergy is producing much more powerful software with less code.

Now we get to my possible contributions to Python and the SIG.

At a minimum, I believe the documentation I produce will be useful to anyone using CXX.  I may be able to expand upon the current work in CXX to make it easier to produce extension modules and classes.  I, of course, would make any CXX extensions I produce available to the community.

I hope that what I produce will be able to benefit the Python community.  To that end, I will probably be asking lots of questions.

Disclaimer:  I can't guarantee that the client's legal department agrees with any of my views.  They are currently examining the Python, Pyro, CXX, IDLE, JPython, and SWIG licenses to see if they will allow us to use any of them in a shippable product.  8-(

Sincerely,
--------
Daryl V. McDaniel               darylm at python.mnet.com    Micronetics
                                    (503) 621-0234        Aloha Research Group
                                                          Portland, Oregon  USA
   "Aloha Research Group", "Mnet", and "mnet"  are trademarks of Micronetics