Mailman 3 August 2015 - Cplusplus-sig

register c++ std::pair<string, string> and std::pair<string*, string*>
by MM Aug. 28, 2015

Aug. 28, 2015

I expose the return type of a C++ function that is a pair of strings with the following snippet: to_python_converter< std::pair<std::string, std::string>, Converter>(); Later, I have a unrelated C++ range type: typedef std::pair<const std::string*,const std::string*> range_t; which I export as: class_<range_t>("range") .def("__iter__" , range(..., ...)); scope().attr("allitems") = object(ptr(&R)); where R is of type range_t in python, allitems can be iterated over. The only issue is I get the following warning: /usr/lib64/python3.4/importlib/_bootstrap.py:321: RuntimeWarning: to-Python converter for std::pair<std::string const*, std::string const*> already registered; second conversion method ignored. Is there a way to avoid this warning? MM

2 8

Extracting base object reference of arbitrary Python object
by Jeremy Murphy Aug. 18, 2015

Aug. 18, 2015

Hi everyone, I have what I assume is a fairly basic or naive question, but I'm still quite new to Boost.Python so after scouring the documentation fruitlessly I need to turn to community wisdom. The short version of my question is: how do I access Python Shapely geometry in C++ using Boost.Python? I have written an algorithm in C++ using Boost.Geometry that I wish to export for use in Python with Shapely geometry. Ideally, I don't want to impose any new programming overhead on the Python side, so I wish for this algorithm to 'just work' with Shapely geometry by using the adaptor facilities in Boost.Geometry. Being a bit naive, what I have done so far is to create some 'proxy' C++ classes to stand for Shapely classes, e.g.: struct Point : public boost::python::object {} struct LinearRing : public boost::python::object {} which I can then adapt by specializing the required traits class templates. My algorithm in C++ looks something like: void native_algorithm(boost::geometry::model::point const &x) {...} void python_algorithm(boost::python::object const &x) { native_algorithm(static_cast<Point const&>(x)); } and I have this working for Point, LineString and LinearRing. However, Polygon has brought me to my knees and challenges my whole strategy of thinly wrapping the Shapely objects with proxy class references. I cannot figure out how to extract (I mean boost::python::extract) a reference to the Shapely geometry in the attributes of a Shapely Polygon. E.g. where 'p' is a const reference to my C++ proxy Polygon class: extract<boost::python::object const &>(p.attr("exterior")); I get the error: TypeError: No registered converter was able to extract a C++ reference to type boost::python::api::object from this Python object of type LinearRing And this is where I am stuck. I just want a reference to this attribute so that I can static_cast it to a const reference to my C++ proxy LinearRing class. Maybe my whole approach is flawed, but if there is a way to solve this specific glitch in my program then I think I'll be OK. I guess I'm surprised that it does not work since the same idea of polymorphism around the python base object class seems to work with function argument references. Anyway if however you recommend a completely different approach, I would be interested in hearing that too. Thanks, cheers. Jeremy

2 1

virtual functions with default implementation
by Stefan Seefeld Aug. 17, 2015

Aug. 17, 2015

Hi, I'm reviewing the Boost.Python tutorial, and I'm stumbling over the section on "Virtual Functions with Default implementations" (http://boostorg.github.io/python/doc/html/tutorial/tutorial/exposing.html#t…). It mentions the need to provide a separate default implementation function as third argument to "def()", without explaining why that is needed. In fact, I'm trying various alternatives (abstract, non-abstract), and I can't find a need for it. All my tests work fine without it. Does anyone know why this is needed, and could perhaps even provide a little test case ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 4

[Boost.Python] Treating boost::variant like a reference?
by Mario Lang Aug. 15, 2015

Aug. 15, 2015

Hi. I am trying (off and on, because it would be useful, but I am not quite there yet) to find a way to make Boost.Python cooperate with Boost.Variant. I sort of managed to make a variant behave like a value. However, things like modification of a variant inside of a container doesn't work, because the variant is converted from/to python everytime it is accessed. Looking at the Boost.Python docs and code, I think there should be a way to treat a variant like a proxy/reference. The only problem is, that Boost.Python would *know* the C++ type of the referenced object only at runtime. While that shouldn't be a problem for Python, It looks like Boost.Python doesn't support this. But maybe there is some way to still acomplish that, and I have missed it? boost.variant is common enough that it would be worthwhile to have boost.python support it as best as possible. It took me quite a while to figure out what I have written below, so, in case there is no better solution, maybe we want to add something about variants to the boost.python docs to get people started a little easier? I've written up what I have found so far here: http://blind.guru/boost_python-and-boost_variant.html Any input appreciated. -- CYa, ⡍⠁⠗⠊⠕

2 1

express pointer ownership
by MM Aug. 13, 2015

Aug. 13, 2015

I have the following class: class T { }; // T has been exposed to python with class_ and free function: void add_T( T* ); Ownership of the T* is taken by this C++ function. If I create an instance of the python version of T, how do I "def" the add_T function? def("add_T", add_T) fails to compile.

3 4

shared_ptr and GIL crash in boost::python (patch)
by Václav Šmilauer Aug. 13, 2015

Aug. 13, 2015

Hi everybody, I have been affected for years by the [1] bug: when shared_ptr for an object created in python is released in c++ in multi-threaded code, Python crashes -- because the shared_ptr_deleter does not lock the GIL before calling Python functions (as the object is destroyed). The referenced bug also contains a 2-line patch; several people report that they have to hand-patch boost::python for their production code. In my case, I can work around the bug by locking the GIL around those few places where this scenario can occur (they are fortunately relatively few in my case), without recompiling boost. I would like to ask someone to look at the patch if it is safe to be applied, and do so. It's been first identified 2 years ago. If I can do something on my part, or other reporters, I am willing to do whatever is necessary to expedite this. Opinions? Cheers, Václav [1] https://svn.boost.org/trac/boost/ticket/8290

2 2

Boost.Python docs update
by Stefan Seefeld Aug. 6, 2015

Aug. 6, 2015

Hi all, I have updated the Boost.Python documentation. The new docs are available at http://boostorg.github.io/python. (For any issues you notice please submit a bug report at https://github.com/boostorg/python/issues. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 2