Mailman 3 March 2004 - Cplusplus-sig

RE: [C++-sig] Re: Wrapper for exception translation
by Gottfried.Ganssauge＠HAUFE.DE Dec. 13, 2004

Dec. 13, 2004

> > ... > >> > >> > Currently, in order to wrap user defined exceptions you need to > >> > > >> > - allocate a python exception using PyErr_NewException > >> > >> Well, no. I don't see any call to PyErr_NewException in > >> libs/python/test/exception_translator.cpp > > > > Right, you don't need to if you are content with RuntimeError > > exceptions. > > or any other pre-packaged exception type provided by Python. > > > My objective was another one: I wanted to create module exceptions > > that are derived from the python "Exception" class. > >> > >> > This function needs to be parametrized using a specific naming > >> > convention > >> > >> It's not clear to me what you're referring to. Are you > sure you mean > >> "naming convention"? > > Yes. > > From the documentation to PyErr_NewException: > > > > ... The __module__ attribute of the new class is set to > the first part > > (up to the last dot) of the name argument, and the > class name is set to > > the last part (after the last dot). > > ...yeah, that's a naming convention, but I don't see how that affects > the parameterization of any function. It is enforced by PyErr_NewException, so you must follow this convention. On the hand I don't think that any user of boost.python is aware of that convention, so I wanted to codify it within my facility. ... > > What I wanted to achieve was the following: > > Create an instance of a translated_exception_handler<> t > which will be > > registered with the library by calling > > register_exception_translator<>(). > > Sorry to be difficult, but I'm going to contradict you. You didn't > want any of that. What you wanted was to create a new Python > exception type in the module which would correspond to a particular > C++ exception type and would be raised at the boundary with Python > whenever a wrapped function threw the C++ exception. Right? Right. I actually described the way to do it within the current library design. > > > Normally t would be destructed by the end of exception_<>() thereby > > leaving a registration to a non-existing translator - very bad > > karma. > > I don't understand any of this. All you have to pass to > register_exception_translator is a function pointer, and functions > live forever. So where's the lifetime issue? A pointer to a function which has access to python exception instance e. As I didn't want to create separate entities I chose to supply a functor instead which has e as a member variable. > > > Because I didn't like to have an additional container for all > > translated_exception_handler<> instances, I chose to store t within > > e's class dictionary. At that moment it seemed to be the easiest > > way to create a wrapper class using class_<> instead of making a > > true python class by hand (and it even works!). You are right, it > > is way too complex, I will change it to the mechanism I used in > > opaque_pointer_converter. > > I don't know what that is, but before you consider doing something > which is again too complex, please consider: > > template <class E> > struct translate_exception > { > static char const* msg; This would need to be defined somewhere. > static object python_exception_type; ... and this would need to be defined somewhere as well. > > static void handler(E const&) > { > PyErr_SetString(python_exception_type.ptr(), msg.c_str()); > }; > > translate_exception(char const* python_exception_name, > char const* msg_) > { > // need fancier name manipulation here > python_exception_type > = object( > handle<>(PyErr_NewException(name))); > msg = msg_; > register_exception_translator<E>(handler); > } > }; > > > Simple. Yes. ... > > I'll make a redesign ... At times you don't see the forrest, just trees ... I think this time I have a simple facility which is also easy to use (no macros). It could be even simpler with a completely different design but frankly - I have no clue how to implement that: We would need a way to somehow derive (in the python sense) a class_<> from PyExc_Exception (the type of the python Exception class) or any other python class (PyErr_NewException() has a base parameter, which could be used for that). At the same time an exception_translator should be registered for that class_<> which uses PyErr_SetObject() to raise a copy of the exception caught. This would allow us to have true Python exceptions in a pythonic sense directly wrapped around the corresponding C++ exception. > > Thnx for your feedback. > > Cool! Looking forward to it. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com Cheers, Gottfried

3 7

Boost Python and Intel C++ 7.1 windows
by Xavier WARIN(Compte LOCAL) - I23 Aug. 16, 2004

Aug. 16, 2004

Hi, While compiling with Intel C++ 7.1 Boost Python , i get this kind of error on class.cpp and a lot of other Boost Python files : C:\boost-1.30.2\boost/type_traits/is_integral.hpp(39): error: class "boost::is_integral<unsigned short>" has already been defined BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) I think that there must be a define that i missed somewhere ! I don't find it Any idea ? Thank you Xavier Warin

2 2

blitz++ and numarray
by Faheem Mitha April 7, 2004

April 7, 2004

Hi, I'm considering the use of the Blitz++ C++ library (http://www.oonumerics.org/blitz/) along with numarray/Numeric. I want to pass an array down to C++ and then manipulate it using Blitz++. My current thinking is to use the Numeric interface to pass down the array, and then copy it to a blitz++ array object. This seems straightforward except I am a little concerned about those reference counting issues, which I don't properly understand (I'm a Python beginner). I do get the impression that it is mainly an issue if I am working with Python objects in C/C++ code, though, and I am mostly going to try to avoid doing so by declaring C++ objects within the C++ code and working with those as much as possible. Other possibilities include somehow using the Boost.Python package, though I am not sure how. One advantage of this is that it apparently takes care of the reference counting issue. However, I don't want to learn yet another API. Also, weave.blitz() from SciPy looks relevant/useful, but this automatically generates its own C++ code, and I'd prefer to write my own. Can anyone suggested a good basic tutorial which discusses the issues of reference counting in a C/C++ API context? I have tried reading the official documentation and will continue to do so, but something gentler would be useful. Comments, suggestions gratefully appreciated. Please cc me on any reply to faheem(a)email.unc.edu. Thanks in advance. Faheem.

3 3

Re: [C++-sig] Re: init function not found [was Re: Problem with
by Aashish Chaudhary April 6, 2004

April 6, 2004

Thanks raul that was a silly mistake :( ... I should have noticed that .. > I didn't know that VC7.0 support had been dropped - at least, not > deliberately! Well that link that you sent in the some mail (on feb 03) (the status of the compilers) showed that there were couple of problems with the VC7.0 but nothing reported for 7.1.. I got the CVS version compiled on Linux .. :) > This looks very confusing to me, because the error message doesn't > seem to match up to what you "did" in Python. Maybe the problem is > very simple though. If you create a shared object called > register_ptr.so you can import it with "from register_ptr import > ....". Python then looks for a Python module or shared object that > matches that name, and in the case of a shared object loads it and > looks for a function called something like initregister_ptr. The > BOOST_PYTHON_MODULE(register_ptr) macro gives you this function, > correctly named. > > > ____________ Problem solved !! Thanks! regards, Aashish ___________________________________ > C++-sig mailing list > C++-sig(a)python.org > http://mail.python.org/mailman/listinfo/c++-sig > __________________________________________________________________________ Aashish Chaudhary Research Assistant Iowa State University E-Mail: aashish(a)iastate.edu Ames, Iowa Telephone: +1 515-441-1178

5 7

wrapping interfaces and supplied implementations
by Brian Peters April 5, 2004

April 5, 2004

Hello All, I'd like first to thank the Boost.Python team and commend them on their creation. Dave Abrahams et.al. have implemented code the likes of which I could not even have conceived, let alone writen. Boost MPL is not something I could ever have thought up. My hope is simply that someone some day finds my work as useful and impressive as I find theirs. I am trying to wrap a library that implements a generic programming approach to computational geometry and topology. To achieve this it defines a number of interfaces it requires to do its job. For developers who do not wish to code the details of these interfaces it also supplies concrete implementations. Having observed Dave Abrahams' penchant for a working test case I have developed a sandbox representing a portion of the library. It has three classes that are abstract base classes: IFacade, IManager, and IProduct. All their pure virtual methods are defined using raw pointers to abstract base classes. The idea is that an application asks the facade for a manager [ IManager* IFacade::manager() ] and then uses the manager to create products [ IProduct* IManager::create(inti i) ]. The products have state that may be changed by the client or other operations of the facade. The manager can also store and retrieve products. A simple user can use the concrete Manager and Product classes supplied through these interfaces, but a more advanced user could derive their own product and manager from the abc's and pass that into the facade [ void IFacade::setManager(IManager* manager) ]. The old addage applies: "The simple should be easy, but the complex should be possible." i.e use the supplied system if you want, but you can always over ride it with something more complex. So now I want to be able to do the same thing in Python. I want to wrap everything so that a simple user can: * see the abstract base classes in python; i.e. the interfaces, their doc strings, etc. * use the supplied implementation of manager and product * derive their own products and manager if they want/need to in python Well, I got it all working! Not only working, but doing cool python stuff too. Being new to python I have found it interesting that arbitrary attributes and methods can be added to any object regardless of its class. I think of a wrapped Product passed out to python from the supplied Manager class as a python envelope containing the C++ Product. I can scribble on that envelope. Spill coffee on it. Crumple it up a bit. I can store it in the manager and throw it away. When I later retrieve from the manager, not only is it the same C++ Product (i.e same address), but it is the same PyObject (i.e. same address, or "id" as they call it in the interpreter), AND it even has the same note scribbled on it and the coffee stain! Its like decorating C++ classes dynamically at run time. I thought the article about C++/Python integration was cool when I read it a few months ago, but now I really see it. The line between Python and C++ is very fluid. ( http://www.cuj.com/documents/s=8188/cuj0307abrahams ) The code is attached below. For reference I am using the following (admittedly somewhat dated) environment: * Python 2.2.2 * Boost 1.30.0 * Windows NT4 with MSVC6 * RH linux 2.4.2-2 with g++ 1.96 I am offering this example to anyone that finds it useful. It is more complex than the examples I found in the documentation and code, yet still simple enough to examine in detail. I am hoping that those in the know will tell me if I have done anything terribly wrong. I will gladly explain why I have done things the way I have and/or share the verbose version of this sandbox that contains a lot more testing functions and cout's. This message is already too long to do so here. thanks, bfp ====================== > Brian Peters > topology<at>eircom<dot>net =============================================================================== ============ abcdf_ext.cpp ==================================================== #include <boost/python.hpp> #include <iostream> #include <sstream> using namespace boost::python; // --- component code ----------------------------------------------- // published interfaces struct IProduct { virtual ~IProduct() {} virtual int value() const = 0; virtual void set(int i) = 0; virtual int other(IProduct* product) const = 0; }; struct IManager { virtual ~IManager() {} virtual IProduct* create(int i) = 0; virtual IProduct* modify(IProduct* product) = 0; virtual int store(IProduct* product) = 0; virtual IProduct* retrieve(int index) = 0; }; struct IFacade { static IFacade* instance(); virtual ~IFacade() {} virtual IManager* manager() = 0; virtual void setManager(IManager* manager) = 0; virtual void update(int i) = 0; virtual std::string notice() const = 0; }; // supplied implementation of interfaces. // only exposed through pointers to the above interfaces. #define MANAGER_CAPACITY 10 struct Product : IProduct { Product(int i): _i(i) {} virtual ~Product() {} virtual int value() const { return _i; } virtual void set(int i) { _i = i; } virtual int other(IProduct* product) const { int v = -10; // TODO Should I throw if NULL == product??? if (product) v = product->value(); return _i*1000 + v; } int _i; }; struct Manager : IManager { Manager(): mCount(0) { memset(mProducts, 0, sizeof(mProducts)); } virtual ~Manager() {} virtual IProduct* create(int i) { return new Product(i); } virtual IProduct* modify(IProduct* product) { product->set(2 * product->value()); return product; } virtual int store(IProduct* product) { int index = -1; if (MANAGER_CAPACITY > mCount) { index = mCount; mProducts[mCount++] = product; } return index; } virtual IProduct* retrieve(int index) { IProduct* product = NULL; if (MANAGER_CAPACITY > index) product = mProducts[index]; return product; } int mCount; IProduct* mProducts[MANAGER_CAPACITY]; }; struct Facade : IFacade { Facade(): mManager(new Manager) {} virtual ~Facade() {} virtual IManager* manager() { return mManager; } virtual void setManager(IManager* manager) { // TODO Deleting the old manager will cause trouble if it has // already been sent out to python. How do I want to handle this? //if (mManager) // delete mManager; mManager = manager; } virtual void update(int delta) { // TODO get a product iterator from IManager here. IProduct* product; for (int i=0; i < MANAGER_CAPACITY; i++) { if (NULL != (product = mManager->retrieve(i))) product->set(product->value() + delta); } } virtual std::string notice() const { return "IFacade::notice() message: hello world!"; } IManager* mManager; }; // the singleton IFacade* theFacade = NULL; IFacade* IFacade::instance() { if (NULL == theFacade) theFacade = new Facade(); return theFacade; } // --- B.P.L. wrapper code ------------------------------------------- // rudimentary exception class struct error { error(std::string message): _msg(message) {} std::string const _msg; }; // ProductProxy provides abc methods to pass IProduct* to python. struct ProductProxy : IProduct { ProductProxy(IProduct* product) : mProduct(product) {} virtual ~ProductProxy() {} virtual int value() const { if (!mProduct) throw error("Bad proxy"); return mProduct->value(); } virtual void set(int i) { if (!mProduct) throw error("Bad proxy"); mProduct->set(i); } virtual int other(IProduct* product) const { if (!mProduct) throw error("Bad proxy"); return mProduct->other(product); } // this virtual function is overridden in ProductBase virtual int otherWrap(object& product) const { if (!mProduct) throw error("Bad proxy"); ProductProxy* proxy = arg_from_python<ProductProxy*>(product.ptr())(product.ptr()); return mProduct->other(proxy); } IProduct* mProduct; }; // ProductBase is the heldtype for ProductProxy to let python derive from IProduct. struct ProductBase : ProductProxy { ProductBase(PyObject* pyobject): ProductProxy(NULL), mSelf(pyobject) {} virtual ~ProductBase() {} virtual int value() const { return call_method<int>(mSelf, "value"); } int default_value() const { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'value'"; throw error(msg.str()); } virtual void set(int i) { call_method<void>(mSelf, "set", i); } void default_set(int i) { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'set'"; throw error(msg.str()); } virtual int other(IProduct* product) const { ProductProxy proxy(product); return call_method<int>(mSelf, "other", ptr(&proxy)); } // this virtual function is overridden from ProductProxy virtual int otherWrap(object& product) const { return call_method<int>(mSelf, "other", product); } int default_other(object& product) const { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'other'"; throw error(msg.str()); } PyObject* mSelf; }; // ManagerProxy provides abc methods to pass IManager* to python. struct ManagerProxy : IManager { ManagerProxy(IManager* manager): mManager(manager), mCount(0) {} ManagerProxy(ManagerProxy& manager) : mManager(manager.mManager), mCount(manager.mCount) { for (int i=--mCount; 0 <= i; --i) mProducts[i] = manager.mProducts[i]; } virtual ~ManagerProxy() {} virtual IProduct* create(int i) { if (!mManager) throw error("Bad proxy"); return mManager->create(i); } // this virtual function is overridden in ManagerBase virtual object createWrap(int i) { if (NULL == mManager) throw error("Bad proxy"); return object(ptr(new ProductProxy(mManager->create(i)))); } virtual IProduct* modify(IProduct* product) { if (NULL == mManager) throw error("Bad proxy"); return mManager->modify(product); } // this virtual function is overridden in ManagerBase virtual object modifyWrap(object& product) { if (NULL == mManager) throw error("Bad proxy"); ProductProxy* proxy = arg_from_python<ProductProxy*>(product.ptr())(product.ptr()); mManager->modify(proxy); return product; // IManager::modify returns its argument, but if another function might not, do this: //IProduct* value = mManager->anotherFunction(proxy); //return value == proxy ? product : object(ptr(new ProductProxy(value))); } virtual int store(IProduct* product) { return mManager->store(product); } virtual int storeWrap(object& product) { ProductProxy* proxy = arg_from_python<ProductProxy*>(product.ptr())(product.ptr()); // make sure side effects will happen mManager->store(proxy->mProduct); int index = -1; if (MANAGER_CAPACITY > mCount) { index = mCount; mProducts[mCount++] = product; } return index; } virtual IProduct* retrieve(int index) { return mManager->retrieve(index); } virtual object retrieveWrap(int index) { // make sure side effects will happen mManager->retrieve(index); if (MANAGER_CAPACITY > index) return mProducts[index]; else return object(); // python's None } IManager* mManager; // just mirror the Manager approach to storage for sandbox int mCount; object mProducts[MANAGER_CAPACITY]; }; // ManagerBase is the heldtype for ManagerProxy to let python derive from IManager. struct ManagerBase : ManagerProxy { ManagerBase(PyObject* pyobject): ManagerProxy(NULL), mSelf(pyobject) {} virtual ~ManagerBase() {} virtual IProduct* create(int i) { object product = call_method<object>(mSelf, "create", i); return arg_from_python<ProductProxy*>(product.ptr())(product.ptr()); } // this virtual function is overridden from ManagerProxy virtual object createWrap(int i) { return call_method<object>(mSelf, "create", i); } object default_create(int i) { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'create'"; throw error(msg.str()); } virtual IProduct* modify(IProduct* product) { ProductProxy proxy(product); return call_method<IProduct*>(mSelf, "modify", ptr(&proxy)); } // this virtual function is overridden from ManagerProxy virtual object modifyWrap(object& product) { return call_method<object>(mSelf, "modify", product); } object default_modify(object& product) { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'modify'"; throw error(msg.str()); } virtual int store(IProduct* product) { ProductProxy proxy(product); return call_method<int>(mSelf, "store", ptr(&proxy)); } virtual int storeWrap(object& product) { return call_method<int>(mSelf, "store", product); } int default_store(object& product) { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'store'"; throw error(msg.str()); } virtual IProduct* retrieve(int index) { object product = call_method<object>(mSelf, "retrieve", index); return arg_from_python<ProductProxy*>(product.ptr())(product.ptr()); } virtual object retrieveWrap(int index) { return call_method<object>(mSelf, "retrieve", index); } object default_retrieve(int index) { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'retrieve'"; throw error(msg.str()); } PyObject* mSelf; }; // after IFacade, but no need to inherit struct FacadeProxy { ~FacadeProxy() {} static FacadeProxy* instance() { return new FacadeProxy(); } object managerWrap() { if (mManager == object()) mManager = object(ptr(new ManagerProxy(IFacade::instance()->manager()))); return mManager; } void setManagerWrap(object manager) { ManagerProxy* proxy = arg_from_python<ManagerProxy*>(manager.ptr())(manager.ptr()); if (NULL != proxy) { mManager = manager; IFacade::instance()->setManager(proxy); } else { std::ostringstream msg; msg << "Object type: " << manager.ptr()->ob_type->tp_name << " not derived from IManager"; throw error(msg.str()); } } void update(int delta) { IFacade::instance()->update(delta); } std::string notice() const { return IFacade::instance()->notice(); } object mManager; }; // exception handling void translate(error const& e) { PyErr_SetString(PyExc_AttributeError, e._msg.c_str()); } // utility functions PyObject* _last; void dumpLast() { std::cout << "dumpLast" << std::endl; std::cout << " last: " << (void*)_last << " [" << (typeid(*_last)).name() << "]" << std::endl; std::cout << " last->ob_refcnt: " << _last->ob_refcnt << std::endl; std::cout << " last->ob_type->tp_name: " << _last->ob_type->tp_name << std::endl; } void dumpPyObject(PyObject* pyobject) { _last = pyobject; // steal for dumpLast std::cout << "dumpPyObject" << std::endl; std::cout << " pyobject: " << (void*)pyobject << " [" << (typeid(*pyobject)).name() << "]" << std::endl; std::cout << " pyobject->ob_refcnt: " << pyobject->ob_refcnt << std::endl; std::cout << " pyobject->ob_type->tp_name: " << pyobject->ob_type->tp_name << std::endl; } void dumpProduct(ProductProxy* proxy) { std::cout << "dumpProduct" << std::endl; std::cout << " proxy: " << (void*)proxy << " [" << (typeid(*proxy)).name() << "]" << std::endl; ProductBase* base = dynamic_cast<ProductBase*>(proxy); if (base) { std::cout << " proxy->mSelf: " << (void*)base->mSelf << " [" << (typeid(*base->mSelf)).name() << "]" << std::endl; std::cout << " proxy->mSelf->ob_refcnt: " << base->mSelf->ob_refcnt << std::endl; std::cout << " proxy->mSelf->ob_type->tp_name: " << base->mSelf->ob_type->tp_name << std::endl; } else { std::cout << " proxy->mProduct: " << (void*)proxy->mProduct << " [" << (typeid(*proxy->mProduct)).name() << "]" << std::endl; } } int useValue_PyObject_ptr(PyObject* product) { return call_method<int>(product, "value"); } int useValue_object_ref(object& product) { return call_method<int>(product.ptr(), "value"); } int useValue_ProductProxy_ptr(ProductProxy* product) { return NULL != product ? product->value() : -1; } ProductProxy* passBack_ProductProxy_ptr(ProductProxy* product) { return product; } object passBack_object(object& product) { ProductProxy* proxy = arg_from_python<ProductProxy*>(product.ptr())(product.ptr()); if (NULL == proxy) return object(); else return product; } BOOST_PYTHON_MODULE(abcdf_ext) { register_exception_translator<error>(&translate); class_<ProductProxy, ProductBase, boost::noncopyable>("IProduct") .def("value", &ProductProxy::value, &ProductBase::default_value, "Returns an int value") .def("set", &ProductProxy::set, &ProductBase::default_set, "Sets an int value") .def("other", &ProductProxy::otherWrap, &ProductBase::default_other, "Returns an int value using another IProduct") ; class_<ManagerProxy, ManagerBase, boost::noncopyable>("IManager") .def("create", &ManagerProxy::createWrap, &ManagerBase::default_create) .def("modify", &ManagerProxy::modifyWrap, &ManagerBase::default_modify) .def("store", &ManagerProxy::storeWrap, &ManagerBase::default_store) .def("retrieve", &ManagerProxy::retrieveWrap, &ManagerBase::default_retrieve) ; class_<FacadeProxy>("IFacade", no_init) .def("instance", &FacadeProxy::instance, return_value_policy<manage_new_object>()) // How do I do a singleton? .staticmethod("instance") .def("manager", &FacadeProxy::managerWrap) .def("setManager", &FacadeProxy::setManagerWrap) // ,with_custodian_and_ward<1, 2>()) // I don't think I need this as returning an object keeps track of reference counts. .def("update", &FacadeProxy::update) .def("notice", &FacadeProxy::notice) ; def("dumpLast", &dumpLast); def("dumpPyObject", &dumpPyObject); def("dumpProduct", &dumpProduct); def("useValue_PyObject_ptr", &useValue_PyObject_ptr); def("useValue_object_ref", &useValue_object_ref); def("useValue_ProductProxy_ptr", &useValue_ProductProxy_ptr); def("ProductProxy_ptr_manage_new_object", &passBack_ProductProxy_ptr, return_value_policy<manage_new_object>()); def("ProductProxy_ptr_reference_existing_object", &passBack_ProductProxy_ptr, return_value_policy<reference_existing_object>()); def("Product_as_object", &passBack_object); // no return_value_policy needed } #include "../../../boost_1_30_0/libs/python/test/module_tail.cpp" ============ abcdf_ext.cpp ==================================================== # test abcdf_ext: Abstract Base Class with DeFaults from abcdf_ext import * class Derived(IProduct): def __init__(self, i): IProduct.__init__(self) self.i = i def value(self): return self.i def set(self, i): self.i = i def other(self, product): return self.i*1000 + product.value() def callValue(product): return product.value() def callOther(product, other): return product.other(other) def callSet(product, i): product.set(i) class DManager(IManager): def __init__(self): IManager.__init__(self) self._products = [] def create(self, i): return Derived(i) def modify(self, product): product.set(product.value()*3) return product def store(self, product): index = len(self._products) self._products.append(product) return index def retrieve(self, index): try: return self._products[index] except: return None E=IFacade.instance() M=E.manager() D=DManager() m = M.create(2) n = M.create(3) m._m = "m" n._n = "n" i1 = M.store(m) i2 = M.store(n) i3 = M.store(M.create(4)) M.retrieve(i1)._m d = D.create(4) E.setManager(D) Dr=E.manager() e=Dr.create(5) f=Dr.create(6) e._e = "e" f._f = "f" Dr.store(e) Dr.store(f) =============================================================================== ===============================================================================

2 1

Newbie needs advice for decision.
by Billy Gnosis April 4, 2004

April 4, 2004

Hi I want to extend and more important embed Python in my Programs. 1. What is the best (easiest way) to extend Python with C++ ? Swig or Boost.Python, or is there something easier ? 2. What is the best (easiest way) to embed Python in a C++ Program ? Boost.Python, the Python/C Api, or is there something easier out there ? 3. General Question: I played a little bit wit the high level embedding of the python interpreter in my C++ Program (#include "Python.h", Py_Initialize()...etc.etc...). Can I somehow compile and link everything statically ? Meaning, I have one binary in the end, that already includes all necessary parts of the python interpreter - when I give this file somebody else, this should be enough to run it no installation of the python interpreter necessary, etc... Is this possible ? Cheers, sb

2 1

Re: Boost Python on Mac OS X
by David Abrahams March 31, 2004

March 31, 2004

Hi James, It's best to post Boost.Python questions to the c++-sig: http://www.boost.org/more/mailing_lists.htm#cplussig James Mastro <jmastro(a)rochester.rr.com> writes: > Hello all, > > I'm trying to use Boost Python on Mac OS X 10.3. I'm following along > with what is at http://www.boost.org/libs/python/doc/tutorial/doc/ > building_hello_world.html. After using bjam like this: > > bjam -sTOOLS=darwin > > the following are built: > > libboost_python.dylib > hello.so > > This seems to be correct. I'm not totally sure where they are supposed > to go, so I put them in next to Python in the Python framework so > Python could find them to import. It found them, but an "import hello" > in Python resulted in: > > ImportError: Failure linking new module: > ../../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/ > debug/shared-linkable-true/libboost_python.dylib: dyld: > /Applications/MacPython-2.3/PythonIDE.app/Contents/MacOS/PythonIDE > can't open library: > ../../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/ > debug/shared-linkable-true/libboost_python.dylib (No such file or > directory, errno = 2) > > Before putting the 2 libs in, "import hello" found nothing. So I > assume Python is finding the hello module now, but not liking it. > Can anyone show me where I've gone wrong? Many thanks. I don't know much about MacOS X, but I'm guessing there's an LD_LIBRARY_PATH or some such that tells it where to look for dynamically linked libraries? If so, you need to modify it to point at libboost_python.dylib, or move the library to a location already in that path. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

Automation of Python object retrieval
by Pierre Barbier de Reuille March 30, 2004

March 30, 2004

I have a problem with the boost::python::object contruction. I'd want to know if there is a way to automate the retrieval of the existing Python object when I hold a Pointer on the C++ base class and that the class is extended in Python. Here's an example of what I do now : ================ In C++ ================ #include <boost/python.hpp> #include <boost/python/make_constructor.hpp> #include <string> #include <memory> using namespace boost::python; struct Base { virtual ~Base() {} virtual std::string toStr() const { return "base"; } virtual bool operator==( Base& b ) { return toStr() == b.toStr(); } }; struct BaseWrap : public Base { BaseWrap( PyObject* self_ ) : self(self_) { Py_INCREF(self); /* Ensure the Python object exists as least as long as the C++ object does */ } BaseWrap( PyObject* self_, const Base& copy) : Base(copy), self(self_) { Py_INCREF(self); } virtual ~BaseWrap() { Py_DECREF(self); } virtual std::string toStr() const { return call_method<std::string>(self, "toStr"); } std::string default_toStr() const { return Base::toStr(); } virtual bool operator==( Base& b ) { return call_method<bool>(self, "__eq__", b); // Naive approach } bool default_eq( Base& b) { return Base::operator==( b ); } PyObject *self; }; struct Holder { Holder( Base* b = NULL ) : hold( b ) {} bool operator==( Holder& other ) { return *hold == *other.hold; } std::string toStr() { return hold->toStr(); } Base& getHold() { return *hold; } Base* hold; }; Holder* makeHolder( std::auto_ptr<Base> b ) { Holder* obj = new Holder( b.get() ); b.release(); return obj; }; BOOST_PYTHON_MODULE(mymod) { class_<Base, std::auto_ptr<BaseWrap> >("Base", init<>()) .def("__eq__", &Base::operator==, &BaseWrap::default_eq) .def("toStr", &Base::toStr, &BaseWrap::default_toStr) ; implicitly_convertible<std::auto_ptr<BaseWrap>, std::auto_ptr<Base> >(); class_<Holder, boost::noncopyable>( "Holder" ) .def( "__init__", make_constructor( makeHolder ) ) .def( "__eq__", &Holder::operator== ) .def( "toStr", &Holder::toStr ) .def( "getHold", &Holder::getHold, return_internal_reference<1>() ) ; } ================ In Python: ================ from mymod import * class Derived(Base): def __init__(self, value): Base.__init__(self) self._value = value def toStr(self): return "Derived with value %s" % self._value def __eq__(self,other): if isinstance(other, Derived): return self._value == other._value return False h = Holder(Derived(10)) h1 = Holder(Derived(10)) h2 = Holder(Derived("10")) h3 = Holder(Derived(11)) print h == h1 # => 0 print h == h2 # => 0 print h == h # => 0 ====================== All the equality tests fails because the other in detected as a Base object and not a Derived object !!! But, if I replace the BaseWrap::operator== by : virtual bool operator==( Base& b ) { static reference_existing_object::apply<Base&>::type convert; BaseWrap* bw = dynamic_cast<BaseWrap*>( &b ); object other; if( bw != NULL ) { other = object( handle<>( borrowed( bw->self ) ) ); } else { other = object( handle<>( convert( b ) ) ); } return call_method<bool>(self, "__eq__", other); } I get the wanted behaviour. But I wonder if there is a cleaner method to do that ? Or at least a method to automate that. It's always the same : take the self PyObject* from the wrapper and use it to build the the boost::python::object. Thanks, Pierre -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68

2 6

Re: Injecting python code to a class
by Raoul Gough March 29, 2004

March 29, 2004

David Abrahams dave at boost-consulting.com Sun Mar 28 22:11:58 EST 2004 wrote: >Raoul Gough <RaoulGough at yahoo.co.uk> writes: >[snip] >> I had a quick look at the injector code you mentioned, but that seems >> to rely on Python code as well. Not that that's a bad thing, but I'm >> looking for a solution to embed within the C++ extension module code, >> which was my original problem - how to insert some Python code as a >> method from within the C++ code. > >Can't you use PyRun_String or similar to evaluate some Python code >from C++? Actually, that was the idea I had originally, but I wasn't sure where to get the necessary function arguments from. PyRun_String needs the global and local dictionaries to operate with - is there any easy way to get these? It would be running within a def_visitor::visit function... Regards, Raoul Gough. ___________________________________________________________ WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards www.yahoo.co.uk/internetcafes

3 3

Re: [C++-sig] Re: MSVC 7.1 Multithreaded Dll Memory Leak [long post]
by Paul Grenyer March 29, 2004

March 29, 2004

Hi > > Well, as I think I put in my original post, the memory leak occurs > even when a program contains only a handle declaration. > > Did you post a minimal example? Yep. :-) > > However, I don't know if this is the post-Py_Finalize memory > > You can't call Py_Finalize when using Boost.Python; if you do, all > bets are off. I'd have guessed you already know that, though(?) We'd pretty much come to that conclusion yes. > > > leak or the growing memory leak I have been experiencing, but it is > > present in the dll runtime and not in the static runtime. > > Well, it seems like you have a small enough test case that you ought > to be able to track it down yourself (?) More than likely. I will at least try. Regards Paul Paul Grenyer Email: paul(a)paulgrenyer.co.uk Web: http://www.paulgrenyer.co.uk Have you met Aeryn: http://www.paulgrenyer.co.uk/aeryn/? Version 0.3.0 beta now available for download.

1 0