[C++-sig] Weave Scipy Inline C++

[David Abrahams]

From: "eric jones" <eric at enthought.com>

> Weave's current incarnation is roughly divided into four parts:
>
> 0. Fancy translation of Python->C/C++ code in blitz() or accelerate()
> 1. Extension function and module code generation for C/C++ snippets
> 2. On demand compilation machinery.
> 3. A "Catalog" that keeps track of extension functions and handles
> dynamic typing issues.
>
> (0) is not used by inline() which is the most heavily used part of weave
> currently.  (0) is the really hard part and is getting attention from
> Pat Miller at LLNL.  Also, I'd like to look at rolling some of Pyrex in
> for this sort of thing.
>
> The semi-overlapping portions of weave and boost are in (1), but they
> definitely have different purposes.  Boost wraps existing C++ code and
> exposes the classes as Python types.  Weave allows you to inline C/C++
> in Python with the variables in Python automatically converted to
> meaningful C++ types (when possible).  Based on this the type mapping
> process for weave is to map Python types/classes into C++ types/classes.
> This is the opposite of what boost or SWIG which map C/C++ code types to
> Python types.

I don't understand what you mean here. Boost maps bidirectionally between
Python and C++ AFAICT.

> Most of the machinery in boost is explicitly for this
> purpose.  Weave *might* be augmented to handling the task of wrapping an
> existing C++ class to be exposed as a Python type/class, but it would be
> some serious work (as yall know) and the task is already well handled by
> boost and SWIG.  So isn't the niche it is trying to fill.
>
> So, to be more explicit.  You would never wrap wxWindows with weave.
> However, since weave is wxPython aware (on windows anyway), you can
> inline  snippets of C/C++ code that manipulate wxWindows objects passed
> from Python into your C/C++ snippet.  For example, we needed a faster
> method of drawing Numeric arrays to the screen on windows.  If you don't
> want to go in and rebuild all of wxPython, so weave is an option.

I don't understand why you are saying that to add functionality which use
components from a library (e.g. wxPython) you need to modify the library.
If weave can generate a piece of non-intrusive C++ which uses the library
components, the user can do that, too.

> This sort of thing and, writing computational kernels, is where weave
> excels.  The user doesn't have to know much about Python's API to get
> this to work.

That, I think, is the key advantage. You could do the same thing with
Boost.Python /and/ get a useful C++ interface for the same functionality
out of it. However, if you don't care about that, weave might end up being
easier.

> As I said earlier, there are some areas where the two tools overlap, but
> there are many regions where they do not.  I'm not sure merging them (at
> least at this point) buys a whole lot.  The code re-use would be
> minimal.
>
> On the other hand, the synergy might be really nice.  I think boost is
> probably about 80-90% of the way to its goal (is this correct?).

First release is in roughly 3 weeks.

>  Weave
> also does (1)-(3) fairly well in the list above.  However, there is a
> *huge* amount of work that can happen in (0), and its potential is
> exciting much like Pyrex and psyco are exciting.  (0) is more compiler
> stuff.  I'm not sure how boost fits, but it may -- I haven't spent
> enough time with boost yet to know.

We're not trying to fill that niche.

> I guess the other thing that would be really nice is a boost_converter
> base class in weave that others who want to expose there boost wrapped
> classes to weave can sub-class.  I already have this for SWIG (at least
> the old SWIG).  Again, doing so is likely to be trivial.

Maybe. I have no idea what's involved on your end.


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com