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

New to Py++
by Rolf Schlup March 30, 2008

March 30, 2008

Hi all, I'm new to Py++ and I need to create bindings for a Visual Simulation control library for the company I work for. The library consists of over 200 classes of which 50 or need to be "exposed" to be usable. I've tried the Py++ GUI, but the C++ code I get from it doesn't compile. There is one main interface class - VSControl - that has methods for returning references to members ( mostly of other classes ). Some of the classes have forward referencing of their dependencies which causes the C++ to completely haywire and I'm thinking it has something to do with how Py++ generates the wrapper code. I'm also having a lot of issues with Call Policies. Mainly, the ones that have with return of reference types are giving me warnings when I generate the C++ code. I've been using the followingcode, but the resulting C++ code only compiles when I manually add the necessary header files to the generated code. But, then when I try to import it, I get unresolved reference errors. If I try to add all necessary files to the builder lines, the warnings and compiler errors increase exponentially. Again, any help or examples that can yield usable binding code will be appreciated. I've included the VSControl header file at the end of this message. Thank you in advance Rolf Schlup **************************************************************************** **************************************************************************** ******************* #!/usr/bin/python import os import sys sys.path.append( '../../../..' ) from pyplusplus import module_builder from pyplusplus.module_builder import call_policies from pygccxml import declarations from pygccxml.declarations import custom_matcher_t as c_matcher from pygccxml.declarations import regex_matcher_t as re_matcher #Creating an instance of class that will help you to expose your declarations mb = module_builder.module_builder_t( files=[ 'VSControl.hpp'] , gccxml_path=r"/usr/local/bin/gccxml" , working_directory=r"/home/rolf/source/ws_stes/BER/cobusiness/test/VisualSyst emTest/VSPython/" , include_paths=['/home/rolf/source/ws_stes/BER/cobusiness/VisualSystem/VSCore ' ,'/home/rolf/source/ws_stes/BER/cobusiness/VisualSystem/VSCommBase' ,'/home/rolf/source/ws_stes/BER/cobusiness/VisualSystem/VSException' ,'/home/rolf/source/ws_stes/UNT/real/Types' ,'/home/rolf/source/ws_stes/BER/cobusiness/VisualSystem/VSCoordConverter' ,'/home/rolf/source/ws_stes/BER/cobusiness/VisualSystem/VSEnumAndTypes' ,'/home/rolf/source/ws_stes/BER/cobusiness/VisualSystem/VSDefFileReader' ,'/usr/include/python/' ,'/home/rolf/source/ws_stes/BER/real/' ,'/home/rolf/source/ws_stes/BER/real/Global' ,'/home/rolf/source/ws_stes/BER/reglobal' ,'/home/rolf/source/ws_stes/BER/cobusiness/' ,'/home/rolf/source/ws_stes/UNT/real/' ,'/home/rolf/source/ws_stes/BER/cobusiness/VisualSystem/VSCommManager' ,'/home/rolf/source/ws_stes/BER/cobusiness/VisualSystem/VSComm' ] , define_symbols=[] ) # The following 2 lines do not have any effect mb.build_code_creator('VSControl') mb.code_creator.add_include( "path.hpp" ) mem_funs = mb.calldefs() mem_funs.create_with_signature = True for mem_fun in mem_funs: if mem_fun.call_policies: continue if not mem_fun.call_policies and (declarations.is_reference(mem_fun.return_type) or declarations.is_pointer (mem_fun.return_type) ): mem_fun.call_policies = call_policies.return_value_policy(call_policies.reference_existing_object ) #Well, don't you want to see what's going on? mb.print_declarations() #Give a name to the module. After this step you should not modify/customize declarations. mb.build_code_creator( module_name='vscontrol' ) #I don't want absolute includes within code mb.code_creator.user_defined_directories.append( os.path.abspath('.') ) #Write code to file. mb.write_module( os.path.join( os.path.abspath('.'),'VSControl_Bindings.cpp' ) ) **************************************************************************** *********************************************************************** #ifndef VSControl_h #define VSControl_h 1 #include "Global/REALGlobal.hpp" #include "VisualSystem/VSCommBase/VSAllPacketDefinitions.hpp" namespace N_VisualSystem { class VSBasePacket; class VSCommManager; class VSConverterBase; class VSMunitionMan; class VSIsectorMan; class VSCreatureMan; class VSSensorMan; class VSCelestial; class VSEntityMan; class VSObjectAllocater; class VSSystem; class VSEffectMan; class VSTerrainMan; class VSHudMan; class VSTextMan; class VSWeatherMan; class VSSightMan; } // namespace N_VisualSystem namespace N_VisualSystem { class VSControl { public: VSControl (); virtual ~VSControl(); virtual bool init (const std::string& a_configFileName, const std::string& a_interfaceName); VSWeatherMan& getWeatherMan (); VSCelestial& getCelestial () const; VSCreatureMan& getCreatureMan () const; VSEffectMan& getEffectMan (); VSEntityMan& getEntityMan () const; VSHudMan& getHudMan (); VSIsectorMan& getIsectorMan () const; VSMunitionMan& getMunitionMan (); VSSensorMan& getSensorMan (); VSSightMan& getSightMan () const; VSSystem& getSystem (); VSTerrainMan& getTerrainMan (); VSTextMan& getTextMan (); virtual bool isUpdateRequested (); void startUpdate (); void endUpdate (); bool getConnectionState () const; void preUpdate (); protected: void createPacketRefList (); void evalIncommingPackets (const std::vector<VSBasePacket*>& a_packetList); void handleSystemResponse (const VSSystemPacket& a_systemPacket); void handleCollisionResponse (); void handleTerrainResponse (const VSTerrainResponsePacket& a_terrainPacket); void handleEffectResponse (const VSEffectResponsePacket& a_effectResponsePacket); VSCommManager& getCommManager (); void handleIsectorResponse (const VSBasePacket& a_isectorPacket); bool m_Initialized; std::vector<const VSBasePacket*> m_PacketRefList; ShVal<VSCommManager> m_CommManager; private: VSControl(const VSControl &right); VSControl & operator=(const VSControl &right); bool operator==(const VSControl &right) const; bool operator!=(const VSControl &right) const; void installDefaultCoordConverter (); ShVal<VSEntityMan> m_EntityManager; ShVal<VSTerrainMan> m_TerrainManager; ShVal<VSSystem> m_System; ShVal<VSSightMan> m_SightManager; ShVal<VSWeatherMan> m_WeatherManager; ShVal<VSTextMan> m_TextManager; ShVal<VSHudMan> m_HudManager; ShVal<VSEffectMan> m_EffectManager; ShVal<VSCelestial> m_Celestial; ShVal<VSSensorMan> m_SensorManager; ShVal<VSCreatureMan> m_CreatureManager; ShVal<VSIsectorMan> m_IsectorManager; ShVal<VSMunitionMan> m_MunitionManager; VSConverterBase* m_DefaultConverter; }; } // namespace N_VisualSystem #endif

2 1