Mailman 3 May 2012 - Cplusplus-sig

boost::python embedding error - runtime - Mac OS X - 1.38
by Igor Karpov Oct. 1, 2014

Oct. 1, 2014

Hi, I am trying to run the following program: #include <iostream> #include <Python.h> #include <boost/python.hpp> using namespace boost::python; using namespace std; int main(int argc, char** argv) { { // Using Python/C Py_Initialize(); PyObject* main_module = PyImport_ImportModule("__main__"); PyObject* globals = PyEval_GetGlobals(); PyObject* locals = PyEval_GetLocals(); PyRun_SimpleString("print 'Hello World, from Python/C!'\n"); Py_Finalize(); } { // Using boost::python Py_Initialize(); object main_module = import("__main__"); object main_namespace = main_module.attr("__dict__"); try { object ignored = exec("print 'Hello World, from boost::python!'\n", main_namespace); Py_Finalize(); } catch (error_already_set const& e) { PyErr_Print(); return 1; } } return 0; } on Linux (both x86 and x86_64), with Ubuntu's default version of Boost (1.34.1) installed, I am able to do so as expected: $ ./embed Hello World, from Python/C! Hello World, from boost::python! on Mac OS X, I get a runtime error: $ ./embed Hello World, from Python/C! Bus Error Running with gdb, this is the stack trace: Hello World, from Python/C! Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () #1 0x00bb618f in PyEval_GetGlobals () #2 0x00bce0dd in PyImport_Import () #3 0x00bce2b0 in PyImport_ImportModule () #4 0x008127d4 in boost::python::import (name=@0xbffff4a8) at libs/python/src/import.cpp:20 #5 0x00004446 in main (argc=1, argv=0xbffff510) at embed.cc:22 For this Mac, boost version is latest (1.38) and python version is: Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Is this a bug? I attached the source and the cmake file I am using to build, for convenience. Thanks, --Igor.

4 6

sendkeys method
by sam Sept. 30, 2013

Sept. 30, 2013

Hello, Is there away(method) in C/C++ programming that make the software think that someone pressed the OK button, similar to sendkeys in VBS (WshShell.SendKeys ("{Enter}")) Thank you, Sam

4 5

Boost::Python: overriding and smart pointers
by Sybren A. Stüvel June 11, 2012

June 11, 2012

Dear list, I'm trying to get my head around shared pointers combined with overloaded methods. I want to create instances of my class both in Python and C++, but for some reason I can't get both to work with the same code. I've constructed a minimal example to show you what I'm trying to do. The full C++ code with syntax highlighting can be found at http://pastebin.com/ZqG79QUL Sorry for the long mail, but I saw no other way to show my issues in a clear and unambiguous way. -------------------------------------- class ExampleObject { public: std::string name; ExampleObject(const std::string & name) : name(name) {} virtual ~ExampleObject() {} virtual int some_number() { return 12; } }; typedef boost::shared_ptr<ExampleObject> ExampleObjectPtr; ExampleObjectPtr create_example_object(const std::string & name) { return boost::make_shared<ExampleObject>(name); } void print_name(ExampleObjectPtr object) { std::cout << "Example object named '" << object->name << "', nr = " << object->some_number() << std::endl; } -------------------------------------- These are the class and functions that I want to wrap. The ExampleObject::some_number method should be overridable in Python. To this end, I've created the following wrapper class: -------------------------------------- struct ExampleObject_wrapper : ExampleObject, wrapper<ExampleObject> { ExampleObject_wrapper(const std::string & name) : ExampleObject(name), wrapper<ExampleObject>() {} virtual int some_number(void) override { if( override func_override = this->get_override("some_number")) return func_override(); return default_some_number(); } int default_some_number(void) { return this->ExampleObject::some_number(); } }; typedef boost::shared_ptr<ExampleObject_wrapper> ExampleObject_wrapper_ptr; -------------------------------------- The Python module is declared as follows: -------------------------------------- BOOST_PYTHON_MODULE(wraptest) { def("create_example_object", &create_example_object); def("print_name", &print_name); class_<ExampleObject_wrapper, boost::noncopyable, ExampleObjectPtr> ("ExampleObject", init<const std::string &>()) .def("some_number", &ExampleObject_wrapper::some_number, &ExampleObject_wrapper::default_some_number) ; } -------------------------------------- This is the Python code that I'm testing with: -------------------------------------- from wraptest import * class ExampleSubclass(ExampleObject): def some_number(self): return ExampleObject.some_number(self) * 2 # Test from Python from_py_obj = ExampleSubclass('from python') print_name(from_py_obj) # Test from C++ from_cpp = create_example_object('from C++') print_name(from_cpp) -------------------------------------- When I compile the module (VS2010, Python 3.2.2, Boost 1.48) and run the Python script, I would expect the object created in C++ to show the number 12, and the object created in Python to show the number 24. However, the output is this: Example object named 'from python', nr = 12 Example object named 'from C++', nr = 12 Running a debugger also shows that the ExampleObject_wrapper methods aren't called at all. When I edit the class_<...> line by replacing ExampleObjectPtr with ExampleObject_wrapper_ptr, the from-Python object works just fine, but the from-C++ object gives me an exception: Example object named 'from python', nr = 24 Traceback (most recent call last): File "C:\workspace\rage\scripts\test_wrapping.py", line 13, in <module> from_cpp = create_example_object('from C++') TypeError: No to_python (by-value) converter found for C++ type: class boost::shared_ptr<class ExampleObject> What should I do to be able to instantiate objects in C++ and Python alike? Kind regards, -- Sybren A. Stüvel http://stuvel.eu/

2 3

Injecting void* and HWND handling code from Py++
by Suresh Joshi June 3, 2012

June 3, 2012

Hello all! I had a question about how to handle void* and HWNDs from within Python using Boost::Python and Py++. Reading through the Py++ documentation, I'm loving how I can slice and dice my classes/wrappers and seemingly do whatever I want with them, but there's still A LOT I haven't figured out. I've found a previous set of similar questions here: http://boost.2283326.n4.nabble.com/Wrapping-and-Passing-HWND-with-Boost-Pyt… but didn't fully understand the automated implementation details. All the relevant code is posted at the end, but my main questions were as follows. (1) Using the win32gui Python library, HWNDs are passed around as ints describing the address of the window. These can be reinterpret_cast'ed into HWNDs in C++ and that seems to work fine. However, using Py++, how can I automatically inject a reinterpret_cast into Foo's constructor, or the initializer list of a constructor wrapper? I've found these commands, .add_declaration_code(...) .add_registration_code(...) .add_wrapper_code(...) but they don't place code where I need it to go. So, is there a command that I should be using? My goal is to not touch my Foo.hpp code (as in, no added code, no helper code), so I would like everything to stay within the Boost::Python generated wrapper code (FooWrapper.cpp). (2) From Python, I would like to manipulate the memory of a buffer stored within Foo. In my REAL code, the only accessor I can use is Address() which returns a void pointer, which Py++/BP flips into an opaque pointer (which I don't think I can use to manipulate m_buffer's memory in Python). One option is ctypes, but I frankly just don't know how to combine that with BP for the purpose of manipulating data behind a void*, even after having looked at the ctypes integration code in the Py++ docs. The other option is to do something like what I did with the fake VoidPtr() accessor. I could create accessors like VoidPtrAsUChar() for example, and then expose those using the return_addressof call policy (hopefully!). If this is, in fact, a valid approach, then I have the same question as above... Given that I can't change the Foo.hpp code, is there a clean way of injecting those AsUChar, AsInt, As... helper methods straight into the wrapper code, so that they call Address() internally and then reinterpret_cast the returned void* into something more useful and accessible in Python? Thanks! -SJ -------------------------------------------------- Here is my trivial Foo class: #include <windows.h> class Foo { public: Foo( const HWND window ) : m_wnd( window ) { const unsigned int size = 10; m_buffer = new unsigned char[size]; for( unsigned int i = 0; i < size; ++i ) m_buffer[i] = i+1; } ~Foo() { delete[] m_buffer; } int IsWindow() { if ( ::IsWindow( m_wnd ) ) return 1; return -1; } void* Address() // In my real code, this is the interface to access memory { return reinterpret_cast< void* >( m_buffer ); } // Fake example accessors void* VoidPtr() { return reinterpret_cast< void* >( m_buffer ); } int* VoidPtrAsInt() { return reinterpret_cast< int* >( m_buffer ); } unsigned char* VoidPtrAsUChar() { return reinterpret_cast< unsigned char* >( m_buffer ); } char* VoidPtrAsChar() { return reinterpret_cast< char* >( m_buffer ); } private: HWND m_wnd; unsigned char* m_buffer; // This buffer could be of any type in real code Foo(); Foo(const Foo&); }; -------------------------------------------------- Here is my Py++ code: mb = module_builder.module_builder_t( files=fileList , gccxml_path=pathToGccXml , working_directory=workingDirectory , compiler='msvc9' ) mb.member_functions( return_type='char *' ).call_policies = call_policies.return_value_policy( call_policies.return_addressof ) mb.member_functions( return_type='int *' ).call_policies = call_policies.return_value_policy( call_policies.return_addressof ) mb.member_functions( return_type='unsigned char *' ).call_policies = call_policies.return_value_policy( call_policies.return_addressof ) mb.build_code_creator( module_name='FooWrapper' ) FooWrapper = os.path.join( os.path.abspath('.'), 'FooWrapper.cpp' ) if os.path.exists( FooWrapper ): os.remove( FooWrapper ) mb.write_module( FooWrapper ) -------------------------------------------------- Which produces this generated code: namespace bp = boost::python; BOOST_PYTHON_MODULE(FooWrapper){ { //::Foo typedef bp::class_< Foo, boost::noncopyable > Foo_exposer_t; Foo_exposer_t Foo_exposer = Foo_exposer_t( "Foo", bp::init< HWND__ * >(( bp::arg("window") )) ); bp::scope Foo_scope( Foo_exposer ); bp::implicitly_convertible< HWND const, Foo >(); { //::Foo::Address typedef void * ( ::Foo::*Address_function_type )( ) ; Foo_exposer.def( "Address" , Address_function_type( &::Foo::Address ) , bp::return_value_policy< bp::return_opaque_pointer >() ); } { //::Foo::IsWindow typedef int ( ::Foo::*IsWindow_function_type )( ) ; Foo_exposer.def( "IsWindow" , IsWindow_function_type( &::Foo::IsWindow ) ); } { //::Foo::VoidPtr typedef void * ( ::Foo::*VoidPtr_function_type )( ) ; Foo_exposer.def( "VoidPtr" , VoidPtr_function_type( &::Foo::VoidPtr ) , bp::return_value_policy< bp::return_opaque_pointer >() ); } { //::Foo::VoidPtrAsChar typedef char * ( ::Foo::*VoidPtrAsChar_function_type )( ) ; Foo_exposer.def( "VoidPtrAsChar" , VoidPtrAsChar_function_type( &::Foo::VoidPtrAsChar ) , bp::return_value_policy< pyplusplus::call_policies::return_addressof >() ); } { //::Foo::VoidPtrAsInt typedef int * ( ::Foo::*VoidPtrAsInt_function_type )( ) ; Foo_exposer.def( "VoidPtrAsInt" , VoidPtrAsInt_function_type( &::Foo::VoidPtrAsInt ) , bp::return_value_policy< pyplusplus::call_policies::return_addressof >() ); } { //::Foo::VoidPtrAsUChar typedef unsigned char * ( ::Foo::*VoidPtrAsUChar_function_type )( ) ; Foo_exposer.def( "VoidPtrAsUChar" , VoidPtrAsUChar_function_type( &::Foo::VoidPtrAsUChar ) , bp::return_value_policy< pyplusplus::call_policies::return_addressof >() ); } } } -- View this message in context: http://boost.2283326.n4.nabble.com/Injecting-void-and-HWND-handling-code-fr… Sent from the Python - c++-sig mailing list archive at Nabble.com.

5 4

Injecting instance of object into main module
by Adam Preble May 30, 2012

May 30, 2012

I wanted to provide an instance of a particular object I'm using for Stackless Python state management. I'm trying to take over the green thread management so I can do my own scheduling--but that's only context. In the attached code, I'm trying to do some of life's more simple things. I have the main module, and the scope for that module. With this, I had hoped I could embed an actual instance of an object. From there I anticipate calling it from Python without having to import or do anything else. I figured I'd take the main script scope, add an object called "runtime", and set it to the one in my C++ runtime. It compiles fine but blows up during runtime with the ever-descriptive "error_already_set()" without a message. This problem only seems to touch the Boost part of the runtime so I don't think that's an issue. I'm using Stackless Python 2.6.5, with Boost 1.49, on Windows Vista with Visual Studio 2010. I had as my inspiration this: http://wiki.python.org/moin/boost.python/HowTo#module_level_objects Which doesn't look to be current. I can't figure out how to use the run-time example there, in particular. It looks like calling interpreter() is not supported, or I have no idea how to make it happen. I'm doing something like this: EmbeddedSynchronization embeddedSync; // A class member up above ... [Did the PyInitialize] boost::python::handle<> mainHandle(boost::python::borrowed(PyImport_AddModule("__main__"))); boost::python::object mainModule(mainHandle); boost::python::scope mainScope(mainModule); boost::python::object class_oClassSync = boost::python::class_<EmbeddedSynchronization, boost::noncopyable>("EmbeddedSynchronization") .def("nap", &EmbeddedSynchronization::beNice) .staticmethod("nap"); mainScope().attr("runtime") = embeddedSync; // Dead right here Stack trace going down in there: > StacklessEmbedding.exe!boost::python::throw_error_already_set() Line 62 C++ StacklessEmbedding.exe!boost::python::expect_non_null<_object>(_object * x) Line 46 C++ StacklessEmbedding.exe!boost::python::converter::detail::return_object_manager_from_python<boost::python::api::object>::operator()(_object * obj) Line 156 + 0x9 bytes C++ StacklessEmbedding.exe!boost::python::call<boost::python::api::object>(_object * callable, boost::type<boost::python::api::object> * __formal) Line 76 + 0x10 bytes C++ StacklessEmbedding.exe!boost::python::api::object_operators<boost::python::api::object>::operator()() Line 54 + 0x14 bytes C++ Anything obviously wrong?

2 2

Mysterious triggerings of "UNREF invalid object" in _Py_ForgetReference
by Adam Preble May 29, 2012

May 29, 2012

This might be one for the main Python lists but since I have a whole lot of stuff wrapped in Boost floating about this problem, I wanted to try the C++-sig for starters. I run my little game experiment for anywhere between 15 and 60 seconds, where it's sending a lot of events and messages around between my C++ runtime and the Python runtime. The code that's failing often completes hundreds of times without fault. I don't know when this started to happen, but it's something of a recent phenomenon. Given the asynchronous stuff in my code, this could have been latent in it the whole time. I'm specifically using Stackless Python 2.6.5 with Boost 1.49, with debug symbols, so I'll paste _Py_ForgetReference so it's in front of you: void _Py_ForgetReference(register PyObject *op) { #ifdef SLOW_UNREF_CHECK register PyObject *p; #endif if (op->ob_refcnt < 0) Py_FatalError("UNREF negative refcnt"); if (op == &refchain || op->_ob_prev->_ob_next != op || op->_ob_next->_ob_prev != op) Py_FatalError("UNREF invalid object"); #ifdef SLOW_UNREF_CHECK for (p = refchain._ob_next; p != &refchain; p = p->_ob_next) { if (p == op) break; } if (p == &refchain) /* Not found */ Py_FatalError("UNREF unknown object"); #endif op->_ob_next->_ob_prev = op->_ob_prev; op->_ob_prev->_ob_next = op->_ob_next; op->_ob_next = op->_ob_prev = NULL; _Py_INC_TPFREES(op); } Here's where I get bit: if (op == &refchain || op->_ob_prev->_ob_next != op || op->_ob_next->_ob_prev != op) Py_FatalError("UNREF invalid object"); I am developing in Visual Studio 2010, and I use the immediate window to test those logic clauses. There are two general situations where it happens: 1. A shared pointer to a message I created in the C++ runtime was passed to an object in the Python runtime, processed, and the control was returned back. It secured and released the GIL in and out of that Python crossing. On the way out of the original C++ function it naturally decrements the shared_ptr use count and starts to destroy it. That is what I want to happen. Call stack of relevant bits: python26_d.dll!Py_FatalError(const char * msg) Line 1679 C python26_d.dll!_Py_ForgetReference(_object * op) Line 2178 + 0xa bytes C python26_d.dll!_Py_Dealloc(_object * op) Line 2197 + 0x9 bytes C wva.exe!boost::python::xdecref<_object>(_object * p) Line 36 + 0xb3 bytes C++ wva.exe!boost::python::handle<_object>::reset() Line 249 + 0xb bytes C++ wva.exe!boost::python::converter::shared_ptr_deleter::operator()(const void * __formal) Line 36 C++ wva.exe!boost::detail::sp_counted_impl_pd<void *,boost::python::converter::shared_ptr_deleter>::dispose() Line 149 C++ wva.exe!boost::detail::sp_counted_base::release() Line 102 + 0xf bytes C++ wva.exe!boost::detail::shared_count::~shared_count() Line 309 C++ If I probe that if condition I see this: op == &refchain 0 op->_ob_prev->_ob_next != op 0 op->_ob_next->_ob_prev != op 0 Nothing was true! How could that conditional trigger? All I can suppose is a gremlin came in and changed a condition on me. Something that has concerned me is I don't grab the GIL when I deallocate these objects. I don't know how I'd do that. I have suspected that was a liability for awhile, but I'm not entirely sure how. 2. Within the same block of C++ code, at the point that I'm trying to transmit the message to the Python-derived object, it'll puke too. So here it has already created a shared_ptr for the message and is triggering a callback into the Python code to handle it. The Python-derived object is being called through a wrapper, and that call has the GIL. This stack trace is much more obnoxious and it's difficult for me to make any sense of it. Note there's some Stackless stuff in there. I think the interpreter is at least starting to call some of the code in the Python derivation, but I haven't been able to figure out how far it gets. I'll take any advice on how to probe this stuff since I feel I am too vague here--look for square brackets on a few lines for some things I figured out: python26_d.dll!Py_FatalError(const char * msg) Line 1679 C python26_d.dll!_Py_ForgetReference(_object * op) Line 2178 C python26_d.dll!_Py_Dealloc(_object * op) Line 2197 + 0x9 bytes C python26_d.dll!tupledealloc(PyTupleObject * op) Line 170 + 0x86 bytes C python26_d.dll!_Py_Dealloc(_object * op) Line 2198 + 0x7 bytes C python26_d.dll!PyObject_CallFunctionObjArgs(_object * callable, ...) Line 2751 + 0x54 bytes C python26_d.dll!handle_callback(_PyWeakReference * ref, _object * callback) Line 881 + 0xf bytes C python26_d.dll!PyObject_ClearWeakRefs(_object * object) Line 928 + 0xd bytes C wva.exe!instance_dealloc(_object * inst) Line 344 + 0xa bytes C++ [This is Boost.Python class.cpp, statically linked] python26_d.dll!subtype_dealloc(_object * self) Line 1020 + 0x7 bytes C python26_d.dll!_Py_Dealloc(_object * op) Line 2198 + 0x7 bytes C [I know here it's deallocating a wrapped type for a 3d vector I was passing around] python26_d.dll!insertdict(_dictobject * mp, _object * key, long hash, _object * value) Line 459 + 0x54 bytes C [It has replaced an existing 3d vector with the passed one, and trying to nuke the old one] python26_d.dll!PyDict_SetItem(_object * op, _object * key, _object * value) Line 701 + 0x15 bytes C python26_d.dll!PyObject_GenericSetAttr(_object * obj, _object * name, _object * value) Line 1504 + 0x11 bytes C python26_d.dll!PyObject_SetAttr(_object * v, _object * name, _object * value) Line 1247 + 0x14 bytes C [value is my 3d vector I am passing around] python26_d.dll!PyEval_EvalFrame_value(_frame * f, int throwflag, _object * retval) Line 2063 C python26_d.dll!PyEval_EvalFrameEx_slp(_frame * f, int throwflag, _object * retval) Line 836 + 0x15 bytes C python26_d.dll!slp_frame_dispatch_top(_object * retval) Line 719 + 0x12 bytes C python26_d.dll!slp_run_tasklet() Line 1204 + 0x9 bytes C python26_d.dll!slp_eval_frame(_frame * f) Line 299 + 0x5 bytes C python26_d.dll!climb_stack_and_eval_frame(_frame * f) Line 266 + 0x9 bytes C python26_d.dll!slp_eval_frame(_frame * f) Line 294 + 0x9 bytes C python26_d.dll!PyEval_EvalCodeEx(PyCodeObject * co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * closure) Line 3294 + 0x6 bytes C python26_d.dll!function_call(_object * func, _object * arg, _object * kw) Line 540 + 0x40 bytes C python26_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2502 + 0x3c bytes C python26_d.dll!instancemethod_call(_object * func, _object * arg, _object * kw) Line 2586 + 0x11 bytes C python26_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2502 + 0x3c bytes C python26_d.dll!PyEval_CallObjectWithKeywords(_object * func, _object * arg, _object * kw) Line 3931 + 0x11 bytes C python26_d.dll!PyEval_CallFunction(_object * obj, const char * format, ...) Line 556 + 0xf bytes C wva.exe!boost::python::override::operator()<boost::shared_ptr<game::IComponentCommunicatable>,unsigned int,boost::shared_ptr<game::ComponentMessage> >(const boost::shared_ptr<game::IComponentCommunicatable> & a0, const unsigned int & a1, const boost::shared_ptr<game::ComponentMessage> & a2) Line 138 + 0xac bytes C++ wva.exe!game::ComponentWrapper::IncomingSignalEvent(boost::shared_ptr<game::IComponentCommunicatable> source, unsigned int id, boost::shared_ptr<game::ComponentMessage> message) Line 234 + 0x4b bytes C++ At least this time the logic condition is true... op == &refchain 0 op->_ob_prev->_ob_next != op 1 op->_ob_next->_ob_prev != op 0 What it's trying to free is of type __PyWeakref_RefType. The 3d vector wrapper has a lot of methods, but I think of particular interest would be the class block. It looks like this: class_<vector3df>("vector3df", init<float, float, float>()) Stuff in Python can create them and they can also get passed around from C++ to Python and back. The impression I get is that something is getting freed before its time. I couldn't tell if it's the shared_ptr self-destructing or the Python GC jumping the gun. I don't have a good impression is what is wrong so I'm finding it hard to write a simplified, self-contained example for the list. I didn't expect a silver bullet with this first message, but I figured somebody had enough experience that I could start isolating things and pare it down.

2 3

Segmentation Fault with Boost.Python and Inheritance
by Gabe Rives-Corbett May 24, 2012

May 24, 2012

Hello, I'm getting a seg fault when trying to call a virtual method on a base class from python. Code is below: #include <memory> namespace boost { template<class T> const T* get_pointer(const std::shared_ptr<T>& ptr) { return ptr.get(); } template<class T> T* get_pointer(std::shared_ptr<T>& ptr) { return ptr.get(); } } #include <Python.h> #include <boost/python.hpp> namespace bp = boost::python; class MyBase { public: MyBase(){} virtual ~MyBase(){} virtual void baseTest() { printf("base test\n"); } }; class MyDerived : public MyBase { public: MyDerived() {} virtual ~MyDerived(){} void derivedTest() { printf("derived test\n"); } }; BOOST_PYTHON_MODULE(PythonTest) { bp::class_<MyBase, std::shared_ptr<MyBase>>("MyBase") .def("baseTest", &MyBase::baseTest); bp::class_<MyDerived, bp::bases<MyBase>, std::shared_ptr<MyDerived>>("MyDerived") .def("derivedTest", &MyDerived::derivedTest); bp::implicitly_convertible<std::shared_ptr<MyDerived>, std::shared_ptr<MyBase>>(); } Does it have to do with using std::shared_ptr for storage? If so is there a way around this? Any help is appreciated. -- Gabe Rives-Corbett

4 5

boost::python with virtual inheritance and g++ c++0x/11 (testcase attached)
by Jonas Wielicki May 23, 2012

May 23, 2012

Moin folks, I recently upgraded to boost::python 1.48 and g++ 4.7 (fedora 17). This broke a project of mine as it crashes when passing an object with virtual inheritance from python back to C++ (e.g. during a method call). A minimal test case is attached. After nearly an hour of debugging in a single gdb session, I found that the value in the PyObject* itself does not change. When the value was first wrapped into a PyObject*, I noted down the address of that and did trial&error dereferencing until I was able to get the actual wrapped object: (gdb) disp (((PyUni::X11Window**)((long*)raw_result)[5])[2]) in the context of /usr/include/boost/python/object/make_instance.hpp:49 (PyUni::X11Window* being the object to be wrapped) The offset 5 was found by inspecting python's object.h, the 2 by guessing (at [5] we find an auto_ptr instance). I added a watchpoint to gdb on that location which did not trigger. Also, after the segfault, I inspected the same adress by replacing raw_result with the appropriate pointer (I noted down the address raw_result was pointing to before continuing from make_instance.hpp:49). Then I was able to reproduce the problem and pin it down to virtual inheritance and g++ -std=c++0x (c++11 does the same), so I built the attached test case. The archive contains (no tarbomb) a single cpp file and two methods to build it. For those for whom it works, there is the simple.Makefile, which relies on hardcoded paths. A CMakeLists.txt is provided for those with cmake and for whom the simple Makefile does not work. Another quick test with boost 1.49 did not fix the issue. -- Jonas

6 21

ANN: pyicl, a python interval container package based on boost.icl
by John Reid May 21, 2012

May 21, 2012

pyicl is a python package that exposes the functionality of boost.icl to python using boost.python. Documentation: http://packages.python.org/PyICL/ PyPi page: http://pypi.python.org/pypi/PyICL/ boost.icl is a general purpose interval container library written in C++. Its author, Joachim Faulhaber, describes it thus: "Intervals are almost ubiquitous in software development. Yet they are very easily coded into user defined classes by a pair of numbers so they are only implicitly used most of the time. The meaning of an interval is simple. They represent all the elements between their lower and upper bound and thus a set. But unlike sets, intervals usually can not be added to a single new interval. If you want to add intervals to a collection of intervals that does still represent a set, you arrive at the idea of interval_sets provided by this library. Interval containers of the ICL have been developed initially at Cortex Software GmbH to solve problems related to date and time interval computations in the context of a Hospital Information System. Time intervals with associated values like amount of invoice or set of therapies had to be manipulated in statistics, billing programs and therapy scheduling programs. So the ICL emerged out of those industrial use cases. It extracts generic code that helps to solve common problems from the date and time problem domain and can be beneficial in other fields as well. One of the most advantageous aspects of interval containers is their very compact representation of sets and maps. Working with sets and maps of elements can be very inefficient, if in a given problem domain, elements are typically occurring in contiguous chunks. Besides a compact representation of associative containers, that can reduce the cost of space and time drastically, the ICL comes with a universal mechanism of aggregation, that allows to combine associated values in meaningful ways when intervals overlap on insertion." Regards, John.

1 0

Re: [C++-sig] Segmentation Fault with Boost.Python and Inheritance
by Gabe Rives-Corbett May 20, 2012

May 20, 2012

Yes I'm using GCC 4.7 on OS X. Is there any possible workaround to use inheritance with GCC 4.7? I'm currently using c++11 threads which aren't supported on GCC 4.6 on OS X. -- Gabe Rives-Corbett Cell: (805) 570-8395 On Friday, May 18, 2012 at 6:00 AM, cplusplus-sig-request(a)python.org wrote: > Send Cplusplus-sig mailing list submissions to > cplusplus-sig(a)python.org (mailto:cplusplus-sig@python.org) > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/cplusplus-sig > or, via email, send a message with subject or body 'help' to > cplusplus-sig-request(a)python.org (mailto:cplusplus-sig-request@python.org) > > You can reach the person managing the list at > cplusplus-sig-owner(a)python.org (mailto:cplusplus-sig-owner@python.org) > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Cplusplus-sig digest..." > > > Today's Topics: > > 1. Segmentation Fault with Boost.Python and Inheritance > (Gabe Rives-Corbett) > 2. Re: Segmentation Fault with Boost.Python and Inheritance > (Jonas Wielicki) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 17 May 2012 17:42:52 -0400 > From: Gabe Rives-Corbett <gabe(a)gaberivescorbett.com (mailto:gabe@gaberivescorbett.com)> > To: cplusplus-sig(a)python.org (mailto:cplusplus-sig@python.org) > Subject: [C++-sig] Segmentation Fault with Boost.Python and > Inheritance > Message-ID: <61DAADFBCA6D4C468EF8216B42EBAE48(a)gaberivescorbett.com (mailto:61DAADFBCA6D4C468EF8216B42EBAE48@gaberivescorbett.com)> > Content-Type: text/plain; charset="utf-8" > > Hello, > > I'm getting a seg fault when trying to call a virtual method on a base class from python. Code is below: > > #include <memory> > > namespace boost { > template<class T> const T* get_pointer(const std::shared_ptr<T>& ptr) > { > return ptr.get(); > } > > template<class T> T* get_pointer(std::shared_ptr<T>& ptr) > { > return ptr.get(); > } > } > > #include <Python.h> > #include <boost/python.hpp> > > namespace bp = boost::python; > > class MyBase > { > public: > MyBase(){} > virtual ~MyBase(){} > > virtual void baseTest() { printf("base test\n"); } > }; > > class MyDerived : public MyBase > { > public: > MyDerived() {} > virtual ~MyDerived(){} > > void derivedTest() { printf("derived test\n"); } > }; > > BOOST_PYTHON_MODULE(PythonTest) > { > bp::class_<MyBase, std::shared_ptr<MyBase>>("MyBase") > .def("baseTest", &MyBase::baseTest); > > bp::class_<MyDerived, bp::bases<MyBase>, std::shared_ptr<MyDerived>>("MyDerived") > .def("derivedTest", &MyDerived::derivedTest); > > bp::implicitly_convertible<std::shared_ptr<MyDerived>, std::shared_ptr<MyBase>>(); > } > > Does it have to do with using std::shared_ptr for storage? If so is there a way around this? Any help is appreciated. > > -- > Gabe Rives-Corbett > >

2 1