Mailman 3 September 2008 - Cplusplus-sig

CMake and getting starting with boost.python
by Braddock Gaskill Aug. 5, 2011

Aug. 5, 2011

Yesterday I became a boost.python user, after years of heavy SWIG usage. I would have started using boost.python years ago except for the bjam learning curve. I spent hours TRYING on multiple occasions, but got lost every time trying to get the page one example to build with bjam. Here is how to build the "greet" example with a four line CMake file: cat >>CMakeLists.txt <<EOF LINK_LIBRARIES(boost_python) INCLUDE_DIRECTORIES("/usr/include/python2.5") LINK_DIRECTORIES("/usr/lib/python2.5") # Not needed? ADD_LIBRARY(hello SHARED hello.cpp) EOF You WILL have to `mv libhello.so hello.so` after building. Works for me under Ubuntu Linux 6.10 after apt-get install cmake python2.5-dev boost-python-dev cmake make mv libhello.so hello.so ipython In [1]: import hello In [2]: hello.greet() Out[2]: 'hello, world' Boost.Python has been a joy to learn and use since I got past bjam. I had a moderately large API wrapped in just my first couple hours of learning (less time than I spent messing with bjam). Any additional advice for using CMake to build boost.python? Braddock Gaskill

4 4

How to import a boost::python dll in windows?
by ichijoji Aug. 5, 2011

Aug. 5, 2011

I'm trying to port some research code that uses boost::python to expose a library to python to windows, but I'm having trouble importing the dll into python. I'm compiling using msvc 2005 and using python 2.5, but when I try to import the module I get this: Traceback (most recent call last): File "main.py", line 1, in <module> import object File "c:\code\sge\code\scripts\object.py", line 1, in <module> import sge ImportError: No module named sge My module is named sge and I'm compiling to sge.dll. Is there some obvious reason why python wouldn't be able to find my dll? When I compile on linux into an so this code works fine. -- View this message in context: http://www.nabble.com/How-to-import-a-boost%3A%3Apython-dll-in-windows--tf3… Sent from the Python - c++-sig mailing list archive at Nabble.com.

4 4

Bug and patch for boost.python with enable_shared_from_this
by Chad Austin March 26, 2009

March 26, 2009

Hi all, A month ago or so we discovered a bug in Boost.Python that manifests when using enable_shared_from_this. Here is a test case that demonstrates the bug: #include <boost/python.hpp> #include <boost/enable_shared_from_this.hpp> using namespace boost; using namespace boost::python; class Test; typedef shared_ptr<Test> TestPtr; class Test : public enable_shared_from_this<Test> { public: static TestPtr construct() { return TestPtr(new Test); } void act() { TestPtr kungFuDeathGrip(shared_from_this()); } void take(TestPtr t) { } }; void Export_test() { class_<Test, TestPtr, noncopyable>("Test") .def("construct", &Test::construct) .staticmethod("construct") .def("act", &Test::act) .def("take", &Test::take) ; } And here is the Python: x = Test.construct() x.take(x) x.act() The bug (as I understand it) is that the shared_ptr_from_python converter creates a new shared_ptr for the Test instance to pass it into C++. This new shared_ptr has a nop deleter, except that it keeps the Python object alive as long as the new shared_ptr is alive. The problem here is that creating a shared_ptr to an object of type T when T is enable_shared_from_this<T> resets the weak pointer inside of enable_shared_from_this<T>. (See shared_ptr's constructors for the details of the implementation.) A fix that passes the test above and has worked for us is to change shared_ptr's constructor to accept a dont_enable_shared_from_this argument and pass that in from the shared_ptr_from_python converter. The patch is attached (against boost 1.33, but the bug didn't look fixed in 1.34 either). Cheers, Chad p.s. I have seen other people with this problem as well. Googling for bad_weak_ptr turns up several results.

3 2

py++ with template member function of template class
by Soloman Jan. 16, 2009

Jan. 16, 2009

Hi, I have met a problem using py++ (pyplusplus) to generate code. First, let's see this code: //////////////////////////////////////////////////////////////////////////////////// // template member function class AFunc { public: template <typename T> T foo(const T& t) const { return t + 1; } }; // we can only fully specialize function template <> string AFunc::foo<string>(const string& t) const { return "string"; }; // the following code is used to generate the instance of template functions #ifdef PYTHONWRAP void AFuncInit() { AFunc a; cout << a.foo<int>(1) << endl; cout << a.foo<float>(1.5f) << endl; cout << a.foo<string>("hello") << endl; }; #endif I followed the instruction in py++ homepage->FAQ, and this works, a call to a.foo<int> will generate an instance of that template member function. But, then, I used template class, and it won't work any more: ///////////////////////////////////////////////////////////////////////// // test template member function in template class // THIS WON'T WORK!!!!!!!!!!!!! template <typename A> class BFunc { public: template <typename T> T foo(const T& t) const; }; template <typename A> template <typename T> T BFunc<A>::foo(const T& t) const { return t + 1; }; #ifdef PYTHONWRAP typedef BFunc<int> BFunc_Int; void BFuncInit() { BFunc_Int a; //mem_fun(&BFunc_Int::foo<int>); //void * p = (void *)(&BFunc<int>::template foo<int>); cout << a.foo<int>(2) << endl; cout << a.foo<float>(2.5) << endl; //cout << a.foo<string>("hello") << endl; }; #endif Look into the generated code, I saw: bp::class_< AFunc >( "AFunc" ) .def( "foo" , (::std::string ( ::AFunc::* )( ::std::string const & ) const)( &::AFunc::foo ) , ( bp::arg("t") ) ) .def( "foo" , (float ( ::AFunc::* )( float const & ) const)( &::AFunc::foo ) , ( bp::arg("t") ) ) .def( "foo" , (int ( ::AFunc::* )( int const & ) const)( &::AFunc::foo ) , ( bp::arg("t") ) ); bp::class_< BFunc< int > >( "BFunc_Int" ); obviously, a call to BFunc_Int::foo<int> hasn't create the template member function instance, can anybody help me? Regards, Xiang.

3 2

Re: [C++-sig] Bug and patch for boost.python with enable_shared_from_this
by Ralf W. Grosse-Kunstleve Dec. 23, 2008

Dec. 23, 2008

No news that I'm aware of. I'd be happy to check in patches, but someone else has to take the lead in communicating with Peter, and updating the unit tests. Ralf ----- Original Message ---- From: Edson Tadeu <e.tadeu(a)gmail.com> To: Development of Python/C++ integration <c++-sig(a)python.org> Sent: Thursday, February 28, 2008 11:45:32 AM Subject: Re: [C++-sig] Bug and patch for boost.python with enable_shared_from_this Any news on this issue? Will this patch get into Boost 1.35? Thanks, Edson On Wed, Feb 13, 2008 at 5:27 PM, Ralf W. Grosse-Kunstleve <rwgk(a)yahoo.com> wrote: Hi Chad, Could you at least ask Peter Dimov if he thinks the dont_enable_shared_from_this patch could be generally useful? Maybe he's OK adding it, then it wouldn't be a big deal fixing Boost.Python, which would probably prevent a lot of confusion and lost time in the future. http://www.boost.org/people/peter_dimov.htm p-d-i-m-o-v-at-m-m-l-t-d-dot-n-e-t Ralf ----- Original Message ---- From: Chad Austin <chad(a)imvu.com> To: Development of Python/C++ integration <c++-sig(a)python.org> Sent: Monday, February 11, 2008 10:10:31 PM Subject: Re: [C++-sig] Bug and patch for boost.python with enable_shared_from_this There probably is a way to prevent boost.python from creating shared_ptrs with a null deleter like it does, but it would require far more knowledge than I have. :) I agree that it would be a better fix, though. On 2/11/08, Ralf W. Grosse-Kunstleve <rwgk(a)yahoo.com> wrote: > > > > Thanks for the patch! I'd love to check this in for you, but for the > change in shared_ptr.hpp you'll need Peter Dimov's approval, and the > shared_ptr documentation would have to be updated. Also, your reproducer > should be turned into a unit test (in boost/libs/python/test). > > Is there any chance that the shared_ptr patch could somehow be avoided? > > Ralf > > > > ----- Original Message ---- > From: Chad Austin <chad(a)imvu.com> > To: c++-sig(a)python.org > Sent: Sunday, February 10, 2008 5:14:45 PM > Subject: [C++-sig] Bug and patch for boost.python with enable_shared_from_this > > Hi all, > > A month ago or so we discovered a bug in Boost.Python that manifests when using enable_shared_from_this. Here is a test case that demonstrates the bug: > > ... -----Inline Attachment Follows----- _______________________________________________ C++-sig mailing list C++-sig(a)python.org http://mail.python.org/mailman/listinfo/c++-sig

3 5

downcasting problems
by Renato Araujo Oct. 13, 2008

Oct. 13, 2008

Hi guys, I'm looking for a solution to my problem with python and c++ objects. I will show this little sample code to introduce my problem: I have this c++ code: ======================== class Shape { public: Shape(Shape *parent=0) { this->_parent = parent; }; Shape* parent() { return this->_parent; }; private: Shape *_parent; }; class Circle : public Shape { public: Circle(Shape *parent=NULL) : Shape(parent) { }; }; ====================== and this python.boost code: ====================== BOOST_PYTHON_MODULE(shapes) { class_<Shape, boost::noncopyable> ("Shape", init<optional<Shape*> > ()) .def("parent", &Shape::parent, return_internal_reference<>()) ; class_<Circle, boost::noncopyable, bases<Shape> >("Circle",init<optional<Shape*> >()) ; } ======================================= the python test is this, and this always output "FAIL": ======================================= if __name__ == '__main__': shape = Shape() circle = Circle(shape) p = circle.parent() if (p == shape): print "OK" else: print "FAIL" How I can fix this without change c++ code? -- Renato Araujo Oliveira Filho

3 3

Re: [C++-sig] Retrieving lvalues using custom converters
by Ralf W. Grosse-Kunstleve Oct. 4, 2008

Oct. 4, 2008

> void do_something( array_t &a ) { ... } > > then, boost.python complains that no converter is found. Now, if the argument > "a" above to do_something needs to be modified, an ugly const_cast is > required. Alternatively, one could do something like the following: > > > void do_something( boost::python::object &obj ) > { > array_t a = boost::python::extract<array_t>( obj ); > ... > } If the above works, this should work, too: void do_something( array_t a ) { ... } > The above works reasonably well in the absence of function overloading. In > essence, the dispatch is now handled manually instead of using boost.python. > But this approach breaks down in the presence of function overloading because > we then start needing another intermediate function to dispatch: > > int do_something( array1_t & ) { ... } > float do_something( array2_t & ) { ... } > return_type do_something_dispatcher( object &o ) { /*dispatch by type in o*/ } extract<> is a two stage process. Your code above is a shortcut for array_t a = boost::python::extract<array_t>( obj )(); The intermediate object has a .check() method to determine if the conversion can succeed. You can use this two test for array1_t and array2_t. http://www.boost.org/doc/libs/1_36_0/libs/python/doc/v2/extract.html > However, this new dispatcher still has a problem with different return types > which I don't know how to solve (short of converting the return type to a > boost::python::object). Yes, make your dispatcher return a boost::python::object. > The problems above can be avoided if boost.python would allow extraction of > lvalues for objects with custom from_python converters. Is this already > possible No. > and have I just missed it in the documentation? No. > Or is extraction of lvalues possible using custom call_policies? No. FWIW: In my own code, I have an array ref<> type, which give you the .begin() and .size(), but not any of the functions that change the size of the array. I have custom converters from the main (reference-counted) array type to ref<>, which I can pass via ref<> const& and I can still modify the array elements. Ralf

4 14

Return value policies for objects with custom to-python converters
by Ravi Oct. 3, 2008

Oct. 3, 2008

Hi, The return value policies from boost.python do not seem to handle objects with custom converters; they seem to handle only those types exposed via boost.python. Attached is some code that handles reference_existing_object for objects with custom converters. However, the interface is unsatisying: 1. The _1 subscripts need to be removed. However, I could not find a way to disambiguate types not exposed through boost.python and those with custom converters. From the perspective of a library user, both the reference_existing_object from boost.python and reference_existing_object_1 from the attached file accomplish exactly the same thing, but the user needs to remember (and know) that certain classes need one vs the other. Could a guru tell me how to plug my converter into boost.python's reference_existing_object? 2. So far, I have used only reference_existing_object. Do the other return value policies need similar special handling for objects with custom to-python converters? How do I figure out which ones do and which ones don't? 3. If there is a satisfactory answer to 1, the resulting technique could be added to boost.python. No new documentation would be necessary, since the existing documentation would convey all the necessary information. In order to submit a patch though, I suppose that some tests are needed. How would one write tests for this functionality? Regards, Ravi

2 5

Importing and internal modules
by Peter LaDow Oct. 2, 2008

Oct. 2, 2008

I'm not sure if my subject is clear (probably not), but I'll try to describe what I am trying to do here. A commercial tool we are using is capable of loading a shared library as an extension, and we'd like to use Python to script much of the extension. To that end, I am embedding Python in our own shared library. The scripted part of the extension is a collection of callback functions from the shared library into Python. I also want to expose an API to the extension. So, I have created an extension using Boost and the BOOST_PYTHON_MODULE, i.e.: namespace bp = boost::python; BOOST_PYTHON_MODULE(foo) { bp::def("foo1", foo1); bp::def("foo2", foo2); } And then I make sure to append foo to the inittab before calling Py_Initialize(): PyImport_AppendInittab("foo", initfoo); Py_Initialize(); No problems so far. In fact, I can use foo in the Python script as long as I import it, i.e. ("from foo import *"). However, here's were I am running into trouble. The scriptable part is a module. It exposes a set of functions, so I'd really like to just import that module, and not execute it. So, I do the following: bp::object main = bp::import("__main__"); bp::object globals(main.attr("__dict__")); // Import "foo" bp::exec("from foo import *", globals, globals); // Import the scriptable code bp::exec("from script import *", globals, globals); And here's an example of a script I am trying to import: def bar1(): foo1() print "Called bar1!" def bar2(): foo2() print "Called bar2!" Now, the import for this fails with: NameError: global name 'foo1" is not defined Unless I put "from foo import *" at the top of the script. I want the 'foo' module already imported into the script. That's the point of the first of the imports. I'm sure I'm missing something obvious here. Any help would be greatly appreciated. Thanks, Pete -- -- "To love for the sake of being loved is human; to love for the sake of loving is Angelic." -- Alphonse de Lamartine

4 5

How to use an opaque pointer ?
by William Marié Oct. 2, 2008

Oct. 2, 2008

Hi, I would like to pass a CObject from C++ to Python without exposing the class i've seen the opaque pointer feature but i can't make it work. Here is what i would like to do : CObject* pObj = ..... ; bp::object callable = .... ; callable( (bpCObject*)pObj ); I tried to do like in the documentation : typedef struct CObject_ *bpCObject; BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(CObject_) but i always have this error at runtime : TypeError: No to_python (by-value) converter found for C++ type: struct bpCObject * and i don't understand, could someone tell me why i have that and what do i have to do to fix the problem ? Thanks a lot William -- View this message in context: http://www.nabble.com/How-to-use-an-opaque-pointer---tp19655049p19655049.ht… Sent from the Python - c++-sig mailing list archive at Nabble.com.

2 1