Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-15 21:42:28

----- Original Message -----
From: "Mark Evans" <mark.evans_at_[hidden]>

> CXX is several things at once. In a roundabout way, your note
> pretty much tells the story. Still I think that argument packing is
> actually one of CXX's strong points. Function arguments always come
> as a CXX (C++) Tuple object, which behaves like a Python Tuple.
> Keywords come in a CXX Dictionary object. Consequently the C++
> code doesn't need to call the Python C API parsing stuff. It's
> quite nice.

In this regard CXX doesn't give you anything over Python's native 'C' API,
except perhaps a slicker interface to the Tuple and Dictionary. Not to
badmouth this, but it means you expend a fair amount of coding effort
manually making sure the right number and types of arguments were passed to
any function, then extracting or converting them to the appropriate C++
types. With py_cpp none of this is neccessary. You just write your classes
in straightforward C++ and export the member functions with a single line of
C++ code.

> CXX interfaces with STL. I haven't
> gotten deep into that side of it. But naturally one is not
> restricted to the use of CXX objects, STL objects, or anything
> else. However it is quite handy to have (for example) a Pythonic
> String object that can turn itself into an STL
> string.

That particular type conversion is automatic with py_cpp. If you have a
   std::string f(const std::string& x) { return x + " pythonically"; }
and you export that with:
   my_module.def(f, "f")
you can simply write in Python:
>>> f('say something')
   'say something pythonically'

> Finally CXX includes its own ExtensionModule class to handle the
> intricacies of writing a Python extension in C++.

I think I've handled that too... haven't I?

> The one thing that CXX does not do, and what drew us into py_cpp
> and ExtensionClass, is the subclassing of C++ code within Pyhton.
> You are correct about that. Off the top of my head, I can't see
> why there would be a conflict between the two packages (CXX and
> py_cpp). If you know of any potential conflicts that will keep
> either one from working properly with the other, by all means notify me.

I don't think there's any problem, unless CXX doesn't "play nice" (e.g.
defines nasty macros which walk on my symbols), but I don't have any reason
to believe it wouldn't be a good citizen. It should even be possible to add
a py_cpp ExtensionClass<> instance to a CXX ExtensionModule.

> Our company has already settled on CXX but we are fishing around
> for a subclassable-C++ capability. We might just settle for
> boring old Python wrappers if it comes to that.

Whatever works. I'm just suggesting that unless you have a specific need for
some of the more esoteric features of CXX, that once you've exported your
first class with py_cpp you'll wonder why you bothered with the other system


Boost list run by bdawes at, gregod at, cpdaniel at, john at