Mailman 3 August 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

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

preventing a copy of the vector when using the vector_indexing_suite
by Scott McKay Sept. 22, 2005

Sept. 22, 2005

Is there a way to set the policy for the vector_indexing_suite to not create a copy of the vector itself (not the internal elements) in python? I have a vector being held by the vector indexing suite defined like... class_< std::vector< smart_ptr<X> > > ( "vector_X" ) .def( vector_indexing_suite< std::vector< smart_ptr<X> > >() ) ; I then have a python extension of a c++ class, which has a method that takes a reference to std::vector< smart_ptr<X> > and populates it by calling the c++ parent class. If I do something like the following... class TestExtendedFactory( x.BasicFactory ): def __init__( self ): super( TestExtendedFactory, self ).__init__() def generate( self, vectorOfSmartPtrXs ): # first generate with our parent super( TestExtendedFactor, self ).generate( vectorOfSmartPtrXs ) ... the entries added by the call to BasicFactory.generate() show up just fine in python, but don't make it back to the original c++ caller of TestExtendedFactory.generate as it is using a copy of the vector not the original one. Thanks Scott

3 7

Boost function call error
by Dirgesh Patel Sept. 16, 2005

Sept. 16, 2005

I have made a .cpp file with boost_python_module inside it and a function call. which looks a little like this: def("copy", copy, imageMorph_copy() [return_value_policy<manage_new_object>()] ); with a overloading operator which looks a little like this: BOOST_PYTHON_FUNCTION_OVERLOADS(imageMorph_copy, copy, 1, 7) the overloader is correct in terms of syntax because i have other functions i am using in same syntax and it works..just fails on this one. here is the error i get: ../python/imageMorph_boost.cpp: In function `void init_module_imageMorph()': ../python/imageMorph_boost.cpp:107: error: no matching function for call to `def(const char[5], <unknown type>, boost::python::detail::overloads_proxy<boost::python::return_value_policy<boost::python::manage_new_object, boost::python::default_call_policies>, imageMorph_copy>)' Any suggestions? i have tried to update my GCC to the latest and greatest. Thanks

4 9

Custom memory management
by Eric Jardim Sept. 13, 2005

Sept. 13, 2005

Hi, as you may know I am wrapping the Qt4 library. Things are going well, but sometimes when the application ends it seg_faults. The problem is that Qt has a light "garbage collection" scheme. Every "QObject" object that you create must has a "parent" object (except toplevels). When the object is deleted, it clean all the mess of its children and so on. Maybe, child objects are beeing killed too soon and the parents can't find them. I am using the with custodian and ward at the constructors, but sometimes I do not create the object. Besides, I suspect that I reference the same C++ object more than one time which might be a problem. Any ideas of what I can do to manage this memory problem? I dropped here the backtrace of one the segfaults. #0 0xb7eda0bd in mallopt () from /lib/tls/libc.so.6 #1 0xb7ed98fb in mallopt () from /lib/tls/libc.so.6 #2 0xb7eda2e6 in mallopt () from /lib/tls/libc.so.6 #3 0xb7ed8f02 in realloc () from /lib/tls/libc.so.6 #4 0xb721739d in qRealloc (ptr=0x821da28, size=512) at global/qglobal.cpp:1098 #5 0xb7232797 in QListData::realloc (this=0x821ba00, alloc=123) at tools/qlistdata.cpp:73 #6 0xb7232ad4 in QListData::prepend (this=0x821ba00) at tools/qlistdata.cpp:115 #7 0xb72c8a2b in QList<int>::prepend (this=0x821ba00, t=@0xbffff480) at qlist.h:408 #8 0xb72c3cac in QConnectionList::remove (this=0x821b9f0, object=0x8266808) at kernel/qobject.cpp:174 #9 0xb72c66b6 in ~QObject (this=0x8266808) at kernel/qobject.cpp:642 #10 0xb72a9e95 in ~QAbstractItemModel (this=0x8266808) at kernel/qabstractitemmodel.cpp:887 #11 0xb72aa4fb in ~QAbstractListModel (this=0x8266808) at kernel/qabstractitemmodel.cpp:1975 #12 0xb79e8139 in ~QListModel (this=0x8266808) at itemviews/qlistwidget.cpp:102 #13 0xb76ab867 in ~QWidget (this=0x8253518) at kernel/qwidget.cpp:898 #14 0xb78c91e7 in ~QFrame (this=0x8253518) at widgets/qframe.cpp:209 #15 0xb7948777 in ~QAbstractScrollArea (this=0x8253518) at widgets/qabstractscrollarea.cpp:209 #16 0xb79a1ed7 in ~QAbstractItemView (this=0x8253518) at itemviews/qabstractitemview.cpp:408 #17 0xb79b445b in ~QListView (this=0x8253518) at itemviews/qlistview.cpp:247 #18 0xb79e4923 in ~QListWidget (this=0x8253518) at itemviews/qlistwidget.cpp:982 #19 0xb76ab093 in ~QWidget (this=0x8240be0) at kernel/qwidget.cpp:898 #20 0xb7d85e92 in ~auto_ptr (this=0xb7de7f2c) at memory:259 #21 0xb7d8694b in ~pointer_holder (this=0xb7de7f24) at pointer_holder.hpp:55 #22 0xb7ccfb2b in boost::python::instance_holder::instance_holder () from /usr/lib/libboost_python-gcc-mt-1_33.so.1.33.0 ... there are more backtraces but are just like "0x000000 in ?? ()" Thanks, [Eric Jardim]

3 3

Boost.Python visibility fix for GCC 4.0
by Allen Bierbaum Sept. 5, 2005

Sept. 5, 2005

It looks like the current version of Boost.Python has a small bug when using the visibility options of gcc 4.0 (i.e. -fvisibility=hidden). I have attached a patch that will fix the problem. It looks like when the code was originally added to test for the GCC version it didn't take into account non 3.x version numbers. This patch should take care of that. Note: This bug rears its head by hiding the extern C initmodule() when you compile a Boost.Python module with "-fvisibility=hidden". Thus the module fails to import into python because the symbol is not found. Hopefully this should fix things up for everyone. -Allen

2 2

what does this message mean?
by Alexis H. Rivera-Rios Sept. 1, 2005

Sept. 1, 2005

Can somebody explain why this message occurs? aclass.MyFunction(object1, object2) did not match C++ signature: MyFunction(class A{lvalue}, class boost::shared_ptr<B> >) I get the error when object2 is a python class that implements the interface specified by B. class Object2Class(B): def(self): self.something def functionFromB(self): # do something here What is the correct way of passing this kind of object to C++? Any help will be greatly appreciated. Thanks, Alexis Programming Tutorial: In Python: To do this, do this In Perl: To do this, do this or this or this or this... In C: To do this, do this, but be careful In C++: To do this, do this, but don't do this, be careful of this, watch out for this, and whatever you do, don't do this __________________________________ Yahoo! Mail for Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail

2 1