[C++-sig] weave plus boost?

[David Abrahams]

----- Original Message -----
From: "eric" <eric at enthought.com>

> That looks very nice -- especially the d[msg] = 5 like syntax.  Can you
> initialize a tuple, dict, list, etc. from a PyObject*?

Now that I look, I think as a matter of fact that you can. I might remove
that ability, though: the library tries not to encourage direct manipulation
of PyObject*, since it's so easy to get the refcounting wrong ("Do I expect
the function to steal a reference?"). Instead, we supply a smart pointer
type called "ref" which you construct from the PyObject* and use that as an
intermediary:

    dict d(ref(p))

The semantics of ref() construction is reference-stealing unless you
explicitly say otherwise:

    dict d(ref(p, ref::increment_count));

Unfortunately, both ways are needed because Python is so inconsistent about
when and where it handles reference-counting for you (e.g. PyObject_SetItem
makes its own reference, but PyTyple_SetItem steals one).

This approach encourages one to consider reference-counting at the boundary
between raw 'C' PyObject* and the much safer world of C++.

> If so, they are
> probably close to interchangeable with the current CXX implementation I
use,
> and it would be easy to create a boost backend to weave.  How far along
are
> these basic objects
> in development?  Can they handle assignments (like the d[msg]=5 statement)
> from int,float,strings, etc. now?

Yep.

> Also, how is the speed compared to using
> Python API calls?

I never measured it but have no reason to think it wouldn't be nearly
equivalent.

> I found that using the nice features of CXX (indexing,
> assignment, etc) in innerloops was hard on performance.

What compiler/version are you using? What are the optimization settings?

Python imposes a limitation that's hard to circumvent: it requires the use
of proxy objects for C++ wrappers of Python containers. These can be hard on
an optimizer.

> > Boost.Python has a different paradigm than weave does.
>
> Right.  My understanding is that boost is CXXish (my main point of
> reference) in flavor  -- i.e. made for writing stand alone C++ libs that
are
> usable from Python.

Close. Boost.Python isn't really for writing C++ libraries, but for wrapping
them. You should in theory be able to grab a library for which you have no
source code and produce a Python extension module in just a few lines of
code.

-Dave