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

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

Base class defined in other header file not included in bp::bases<>
by Haridev, Meghana Sept. 14, 2008

Sept. 14, 2008

Hi Folks, I'm having some trouble generating boost-python wrapper code using pyplusplus for a derived class which has one of its base classes defined in another file. Simple scenario: mydir/ other.hpp: class baseB{ }; hierarchy.hpp: #include "other.hpp" class baseA{ }; class derivedC: public baseA, public baseB{ }; generate_code.py: import os from pyplusplus import module_builder mb = module_builder.module_builder_t( files=['hierarchy.hpp'] ) mb.build_code_creator( module_name='inherit' ) mb.code_creator.user_defined_directories.append( os.path.abspath('.') ) mb.write_module('boost_hierarchy.cpp') ------------------------------------------------------------------------ ------------------------------------------------- Generated code (boost_hierarchy.cpp) looks like this: // This file has been generated by pyplusplus. #include "boost/python.hpp" #include "hierarchy.hpp" namespace bp = boost::python; BOOST_PYTHON_MODULE(inherit){ bp::class_< baseA >( "baseA" ); bp::class_< derivedC, bp::bases< baseA > >( "derivedC" ); } How can I get pyplusplus to add 'baseB' to bp::bases<> for 'derivedC' class when 'baseB' class is defined in another file (present in the same directory or different directory)? When I move the definition of 'baseB' class to hierarchy.hpp, boost wrapper for 'derivedC' is correctly generated as: bp::class_< derivedC, bp::bases< baseA, baseB > >( "derivedC" ); Thanks, -Meghana.

3 9

ANNOUNCE: PyBindGen 0.8
by Gustavo Carneiro June 3, 2008

June 3, 2008

The other day I released PyBindGen 0.8. Main news is that it features a new experimental header file scanner based on pygccxml (i.e., it's similar to py++ in scope, if not in maturity, but does not use boost.pythonunderneath). == What == PyBindGen is a Python module that is geared to generating C/C++ code that binds a C/C++ library for Python. It does so without extensive use of either C++ templates or C pre-processor macros. It has modular handling of C/C++ types, and can be easily extended with Python plugins. The generated code is almost as clean as what a human programmer would write, and does not depend on any library or header files besides Python itself. == Where == https://launchpad.net/pybindgen/ == NEWS == - Support C++ instance attributes through getter/setter methods - Support functions as methods of C++ classes - Support the PyObject* type - Support unsigned int, C strings (char*) (from Mark Lee) - Add basic support for enum types - New experimental automatic module generator based on C/C++ header file scanner and annotations in comments, using pygccxml - Some bug fixes -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert

3 6

Re: [C++-sig] Merging indexing_v2 to mainline
by Ralf W. Grosse-Kunstleve May 18, 2008

May 18, 2008

Hi Raoul, Nice to hear from you! Is indexing_v2 fully backward compatible with the current indexing suite? If not, is it technically feasible to change indexing_v2 so that it can co-exist with the current indexing suite? After so many years, I fear too many things will break if indexing_v2 isn't fully backward compatible. But it would be very nice if it were generally available. Ralf

5 8

Raoul Gough's container suite with svn boost-trunk boost.python?
by John Reid May 18, 2008

May 18, 2008

Has anyone tried using Raoul's container suite with the svn boost-trunk? I'm getting the following error: C:\Dev\ThirdParty\boost\boost-trunk\boost/python/detail/caller.hpp(236) : error C2903: 'extract_return_type' : symbol is neither a class template nor a function template C:\Dev\ThirdParty\boost\boost-trunk\boost/python/detail/caller.hpp(232) : while compiling class template member function 'boost::python::detail::py_func_sig_info boost::python::detail::caller_arity<2>::impl<F,Policies,Sig>::signature(void)' with [ F=boost::python::list (__cdecl *)(std::vector<biopsy::binding_hit> &,boost::python::indexing::slice), Policies=boost::python::indexing::detail::postcall_override<boost::python::indexing::default_container_policies>, Sig=boost::mpl::vector3<boost::python::list,std::vector<biopsy::binding_hit> &,boost::python::indexing::slice> ] So the problem seems to be there is no extract_return_type in boost::python::indexing::detail::postcall_override<boost::python::indexing::default_container_policies> If I remember correctly, I've installed Roman's version by copying it into boost/python/suite/indexing John.

3 6

'iteritems', 'iterkeys' and 'itervalues' in dict
by Nindi Singh April 11, 2008

April 11, 2008

Apolgies for not putting the subject line in my last email. In the Boost.Python dict class there are methods 'iteritems', 'iterkeys' and 'itervalues' all returning objects. How exactly are you supposed to use these objects (iterators) ? ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

2 1

boost.python: when does python call c++ destructors?
by Sebastian Walter March 7, 2008

March 7, 2008

Hello, I have compiled a python module with boost.python that exposes the functionality of a c++ class that has a constructor and destructor and an overloaded operator*. The complete c++ code and wrapper can be found at the bottom of this email: But at first the python script that gives me headaches: /* test.py */ /*-----------*/ #!/usr/bin/env python import myclass a = myclass.asdf() b = myclass.asdf() c = a * b d = a * c /* output of test.py */ /*-----------------------*/ wronski(walter):~/workspace/code_tests/boost_python> ./test.py called constructor with loc: 0 called constructor with loc: 1 called operator* with locs: (0,1) called constructor with loc: 2 called destructor with loc: 2 ?!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! called operator* with locs: (0,2) called constructor with loc: 2 called destructor with loc: 2 called destructor with loc: 0 called destructor with loc: 2 called destructor with loc: 1 called destructor with loc: 2 The problem that I don't understand: a*b calls the constructor of a temporary object that is assigned loc=2 and then directly after that the destructor is called! ...? I expected the new temporary object to get assigned to the name c! What bugs me even more is that there are 4 constructor calls but 6!! destructor calls! How can this happen? Is there something im overlooking? Is this intended behavior of Python/Boost.Python ? How could I avoid it? thanks in advance, Sebastian Walter The corresponding boost.python wrapper and c++ code: /* mainclass.hpp */ /*----------------------*/ #ifndef MAINCLASS_HPP #define MAINCLASS_HPP #include <iostream> #include <vector> using namespace std; class asdf{ public: int loc; asdf(); ~asdf(); friend const asdf operator*(const asdf &lhs, const asdf &rhs); }; #endif /* mainclass.cpp */ /*----------------------*/ #include "mainclass.hpp" int global_int=0; asdf::asdf(){ loc = global_int; cout<<"called constructor with loc:\t"<<loc<<endl; global_int++; } asdf::~asdf(){ cout<<"called destructor with loc:\t"<<loc<<endl; global_int--; } const asdf operator*(const asdf &lhs, const asdf &rhs){ cout<<"called operator* with locs:\t"<<"("<<lhs.loc<<","<<rhs.loc<<")"<<endl; return asdf(); } /* wrapper.cpp */ /*------------------*/ #include "boost/python.hpp" #include "mainclass.hpp" BOOST_PYTHON_MODULE(myclass) { using namespace boost::python; class_<asdf>("asdf") .def(self * self) ; }

4 8