Mailman 3 September 2005 - Cplusplus-sig

GCC version compatibility
by David Abrahams April 15, 2006

April 15, 2006

The following message is a courtesy copy of an article that has been posted to gmane.comp.python.devel as well. Recently people testing Boost.Python with GCC on Linux have reported that the extensions being tested have to be compiled with exactly the same version of GCC as the Python they're being loaded into, or they get mysterious crashes. That doesn't correspond to my past experience; it has always been true that, as long as the compiler used to build Python and the one used to build the extension have compatible 'C' ABIs, we've been okay. Yes, if you were going to pass types like FILE* across the Python/C API, then you additionally need to be sure that the two compilers are using the same 'C' library. That said, none of the Boost.Python tests do that. I'm wondering if there has been a well-known recent change either in Python or GCC that would account for these new reports. Any relevant information would be appreciated. -- Dave Abrahams Boost Consulting www.boost-consulting.com

8 36

RE: Wrapper for exception translation
by Gottfried.Ganssauge＠HAUFE.DE April 4, 2006

April 4, 2006

> -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Monday, December 13, 2004 1:04 PM > To: c++-sig(a)python.org; Gottfried Ganßauge > Subject: Re: Wrapper for exception translation > > > Gottfried Ganßauge wrote: > > Hi Dave, > > > > I digged through the class_<> implementation and I think I > know what I > > must do to implement it. Like you suggested I would add another > > argument to the class_base constructor which is used as > another base > > class for the newly created class. > > Hi Gottfried, Hi Dave, > > I don't know if you're still listening, but today I offered to > implement this patch on the C++-sig (see my other post). > Are you still interested? I am still listening but was buried deeply with work so I even had to abandon the work already invested into this. Nonetheless: Yes - I'm still interested. Cheers, Gottfried P.S.: What second Post? I got 2 Copies of this one. > > > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com >

5 9

Trying to clone (again)
by Paul F. Kunz Feb. 24, 2006

Feb. 24, 2006

I'm trying to clone a Python object from C++. The Python class inherits from an exposed C++ base class. To avoid the dangling pointer problem, I keep a Python reference to the created Python object like this... from hippo import FunctionBase # Define a class in Python that is derived from C++ base class _clones = [] class Linear ( FunctionBase ) : def __init__ ( self ) : FunctionBase.__init__( self ) self.initialize () def clone ( self ) : _clones.append ( Linear () ) return _clones[-1] Then in the C++ wrapper class, I have FunctionBase * FunctionWrap:: clone () const // overrides FunctionBase::clone() { #ifndef HAVE_OLD_PYTHON PyGILState_STATE state = PyGILState_Ensure (); object py_result; if (override clone = this->get_override("clone")) { try { // The Python class author overrode clone; do // whatever she says py_result = clone(); } catch ( error_already_set & e ) { PyErr_Print (); handle_exception (); PyGILState_Release ( state ); return 0; } } else { The Python implemented clone() member function is called but I get the following error message on return ... TypeError: No registered converter was able to extract a C++ reference to type boost::python::api::object from this Python object of type Linear Any suggestions?

3 12

Re: exporting __stdcall methods
by David Abrahams Feb. 11, 2006

Feb. 11, 2006

"John Maddock" <john(a)johnmaddock.co.uk> writes: >> Files like boost/type_traits/detail/is_mem_fun_pointer_tester.hpp >> which are outside the Boost.Python library would need to be enhanced >> to deal with __stdcall, etc. > > Should now be fixed in cvs: provided the changes don't break anything else > of course! Fantastic! Thanks, John! -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 8

Patches for pyste
by Allen Bierbaum Dec. 27, 2005

Dec. 27, 2005

I have a patch that makes a couple of small changes to pyste. 1. Fix bug (??) where using pyste with gcc 4.0 and gccxml throws an exception for trying to convert NoneType to string in declarations.py. It looks like there are some cases where self.name can be none and in these cases the code fails. I modified the code to explicitly call str(self.name) when the name string is needed. It works fine for me. 2. Added feature of declaring an entire class final. I found myself often wanting to eliminate all polymorphic behavior for a class and the only way that is currently supported is to explicitly call final() on all virtual methods. This change allows you to call final() on a class as a whole. -Allen

4 4

Raw constructor (i.e. combination of make_constructor and raw_function)
by Hans Meine Nov. 17, 2005

Nov. 17, 2005

Hi! I guess I am not the first one trying to do this, but the closest discussion I could find did not solve this topic: http://mail.python.org/pipermail/c++-sig/2005-June/008959.html I am trying to do something like python::class_<MyVector>("PythonVector", python::no_init) .def("__init__", python::raw_function(&createVector, 1)); But this gives the vector as first element of the args tuple to createVector(). Now, my createVector looks like this: MyVector createVector(const python::tuple &args, const python::dict &) { int size = python::len(args); MyVector result(size); for(int i=0; i<size; ++i) result[i] = python::extract<double>(args[i])(); return result; } Is there a way to combine the functionality of raw_function and make_constructor? (I even tried staticmethod("__init__") ;-) ) -- Ciao, / / .o. /--/ ..o / / ANS ooo

4 10

Re: [C++-sig] how to handle bare references with a shared_ptr HeldType
by Gregory Price Nov. 1, 2005

Nov. 1, 2005

Hans Meine wrote: > Hmm. What about return_internal_reference (which I am using a lot)? > AFAICS, the C++ A object will not be deleted as long as B is not deleted, > because of the shared ptr. OTOH, during the lifetime of the A python > wrapper, B will not get deleted because of the custodian-ward relationship > initialized via return_internal_reference. Does that make sense? I agree with the second half of that -- return_internal_reference will keep the B instance alive as long as the wrapped A instance exists. But now say the wrapped A instance dies; the HeldType=shared_ptr<A> instance will think it's the only shared_ptr for that A instance, and will delete it. Now the shared_ptr<A> inside the B instance is dangling. I've lost as soon as I let Boost.Python create a new shared_ptr<A> from the bare A& -- the only way to avoid a dangling pointer then is to ensure that the A instance never dies at all. Is there a way to tell Boost.Python not to make a shared_ptr for this return value -- to override the HeldType just for this function's return value? Alternatively, to tell Boost.Python always to leave bare A references as they are? Or perhaps there's a simpler solution that I'm missing. Thanks, Greg ============================================================================================= Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ==============================================================================================

4 7

Re: [C++-sig] how to handle bare references with ashared_ptrHeldType
by Gregory Price Nov. 1, 2005

Nov. 1, 2005

David Abrahams wrote: > > Here I use return_internal_reference on make_A; > > so I should get a Python object "a" holding the C++ A > > as a raw pointer. But there's no trouble passing "a" > > to get_x, which wants a shared_ptr<A>. > > What is Boost.Python doing that makes this work? > > It creates a shared_ptr whose custom deleter decrements the > refcount on the Python object owning the A. Ah, very slick. And when I try the same code using the custom shared pointers I've actually got, it tells me:: Traceback (most recent call last): File "<stdin>", line 1, in ? Boost.Python.ArgumentError: Python argument types in test.get_x(A) did not match C++ signature: get_x(Common::SmartPtr<A>) since, naturally enough, it doesn't know how to do something so smart with these custom pointers. I think I understand now what's going on. So as Hans said, the answer is to use return_internal_reference. Thanks to both of you! I'd understood the opposite behavior from the documentation, namely that Boost.Python would create a new shared_ptr (or HeldType generally) from a returned A&. Most pertinent is the passage (in the class.hpp docs) Because Boost.Python will always allow wrapped instances of T to be passed in place of HeldType arguments, specifying a smart pointer for HeldType allows users to pass Python T instances where a smart pointer-to-T is expected. which I now see is making exactly the point you say, David, but which I'd read as saying that Boost.Python would convert instances of T to instances of HeldType. (In hindsight I see there's no way it could have known how to do that, not for the custom shared-pointers I've been using.) I think this reading was encouraged by the suggestion in the paragraph just above it that this is exactly what's done when HeldType is derived from T. Here's another version of that passage: HeldType may be a smart pointer to T. In this case Boost.Python will allow Python T instances to hold either a C++ T instance or a C++ HeldType instance. If HeldType is shared_ptr<T>, a from_python converter will be registered to accept a Python T instance holding a C++ T instance and return a shared_ptr<T> instance with a custom deleter that decrements the Python refcount. Is this right? In particular, have I correctly gathered the following about how Boost.Python works (and about its terminology): When a Boost.Python function is called (in Python), it finds a from_python converter to convert each of the arguments to a C++ object of the required type. Similarly, after invoking the underlying C++ function, a to_python converter is found to convert its return value into a Python object. Where in the documentation is this sort of orientation material found? (Or where should it be?) Thanks for all your help. Greg ============================================================================================= Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ==============================================================================================

2 1

c++ bool to python bool
by Nicolas P. Rougier Nov. 1, 2005

Nov. 1, 2005

Hello, This is certainly a newbie question but how do I get boost python to wrap a c++ bool type to a python bool type ? Here is what I tried: #include <boost/python.hpp> class Boolean { public: Boolean (bool v) : value(v) {} bool value; }; BOOST_PYTHON_MODULE(boolean) { using namespace boost::python; class_<Boolean>("Boolean", init <bool>() ) .def_readwrite ("value", &Boolean::value); } But the value property is considered as being an 'int' in python (and it's important for me to get the right type). I saw that boost python changelog indicates support for python's bool type but I found no further documentation. Did I miss something ? Nicolas Rougier.

2 1

Regression in Boost.Python v1.33
by Niall Douglas Oct. 27, 2005

Oct. 27, 2005

The TnFOX Python bindings are failing to compile on MSVC7.1 in BPL v1.33 when they worked in v1.32: D:\Tornado\Tn\TClient\boost\boost\python\converter\registered.hpp(88) : error C2784: 'const boost::python::converter::registration &boost::python::converter::detail::registry_lookup(T &(__cdecl *)(void))' : could not deduce template argument for 'T1 &(__cdecl *)(void)' from 'volatile const boost::add_reference<T>::type (__cdecl *)(void)' I see some changes have been made in converter/registered.hpp, namely: template <class T> registration const& registered_base<T>::converters = registry::lookup(type_id<T>()); ... has become: template <class T> registration const& registered_base<T>::converters = detail::registry_lookup((T(*)())0); Is this known about, and why was it done when the old code seems perfectly fine? Cheers, Niall

2 20