From mthamer at firaxis.com Wed Mar 2 01:54:57 2005 From: mthamer at firaxis.com (Mustafa Thamer) Date: Tue, 1 Mar 2005 19:54:57 -0500 Subject: [C++-sig] Projects using Boost.Python Message-ID: <000401c51ec2$74913810$752a10ac@firaxis.com> Games Civilization IV "The fourth game in the PC strategy series that has sold over five million copies, Sid Meier's Civilization IV is a bold step forward for the franchise, with spectacular new 3D graphics and all-new single and multiplayer content. Civilization IV will also set a new standard for user-modification, allowing gamers to create their own add-ons using Python and XML. Sid Meier's Civilization IV will be released for PC in late 2005. For more information please visit www.firaxis.com or write kgilmore at firaxis.com." Boost.Python is used as the interface layer between the C++ game code and Python. Python is used for many purposes in the game, including map generation, interface screens, game events, tools, tutorials, etc. Most high-level game operations have been exposed to Python in order to give modders the power they need to customize the game. -Mustafa Thamer Civ4 Lead Programmer -------------- next part -------------- An HTML attachment was scrubbed... URL: From boost_list at openseaconsulting.com Wed Mar 2 17:08:02 2005 From: boost_list at openseaconsulting.com (James Fowler) Date: Wed, 02 Mar 2005 11:08:02 -0500 Subject: [C++-sig] Projects using Boost.Python In-Reply-To: <000401c51ec2$74913810$752a10ac@firaxis.com> References: <000401c51ec2$74913810$752a10ac@firaxis.com> Message-ID: <4225E4E2.10909@openseaconsulting.com> wow. - james Mustafa Thamer wrote: >Games > > > >Civilization IV > > > >"The fourth game in the PC strategy series that has sold over five million >copies, Sid Meier's Civilization IV is a bold step forward for the >franchise, with spectacular new 3D graphics and all-new single and >multiplayer content. Civilization IV will also set a new standard for >user-modification, allowing gamers to create their own add-ons using Python >and XML. > > > >Sid Meier's Civilization IV will be released for PC in late 2005. For more >information please visit www.firaxis.com or write kgilmore at firaxis.com." > > > >Boost.Python is used as the interface layer between the C++ game code and >Python. Python is used for many purposes in the game, including map >generation, interface screens, game events, tools, tutorials, etc. Most >high-level game operations have been exposed to Python in order to give >modders the power they need to customize the game. > > > >-Mustafa Thamer > >Civ4 Lead Programmer > > > > > > >------------------------------------------------------------------------ > >_______________________________________________ >C++-sig mailing list >C++-sig at python.org >http://mail.python.org/mailman/listinfo/c++-sig > > -- __________________________________________________________ James Fowler, Open Sea Consulting http://www.OpenSeaConsulting.com, Marietta, Georgia, USA Do C++ Right. http://www.OpenCpp.org, opening soon! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mzhangyh at yahoo.com Wed Mar 2 23:47:21 2005 From: mzhangyh at yahoo.com (Michael Zhang) Date: Wed, 2 Mar 2005 14:47:21 -0800 (PST) Subject: [C++-sig] AttributeError: 'Ipp8uC3ParticleFilter' object has no attribute 'initTrack' Message-ID: <20050302224722.98190.qmail@web53703.mail.yahoo.com> Hello, I have built a model in C with files 'Ipp8uC3ParticleFilter.c' and 'Ipp8uC3ParticleFilter.h'. But when I am trying to load a method "initTrack" I got the following error. Traceback (most recent call last): File "ShowAll_PF.py", line 137, in _threadEntry self.tracker.initTrack(left, top, width, height); AttributeError: 'Ipp8uC3ParticleFilter' object has no attribute 'initTrack' My .c and .h file are created by modifying a sample that works fine. Thanks for you any suggestion, Michael __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From seefeld at sympatico.ca Fri Mar 4 03:41:58 2005 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu, 03 Mar 2005 21:41:58 -0500 Subject: [C++-sig] class_, HeldType, and NonCopyable...please help !! Message-ID: <4227CAF6.3050100@sympatico.ca> hello, I'm trying to wrap an API but having problems at runtime that I can't quite figure out how to resolve. Let me describe the situation: My API deals with pointers referring to objects that are garbage collected. The objects are always created by factories and never directly allocated via 'new'. It thus seemed natural to declare class_ node("Node", no_init); but this produced an error because of Node having abstract methods. Fair enough. My next attempt was to instruct bpl that 'Node' can't be copied: class_ node("Node", no_init); That compiles. However, I also have a 'Visitor' class with a 'visit(Node *)' method that I expose, and implement as class VisitorWrapper : public Visitor { public: ... virtual void visit(Node* n) { call_method(self, "visit", n);} ... }; The call to "visit" above, when executed, results in the exception: "TypeError: No to_python (by-value) converter found for C++ type: Node" and here I'm lost. Going back to the documentation I find: NonCopyable If supplied, must be boost::noncopyable. Suppresses automatic registration of to_python conversions which copy T instances. Required when T has no publicly-accessible copy constructor. (on http://boost.org/libs/python/doc/v2/class.html) However, 'T' here is 'Node', not the HeldType 'Node *', and so I wonder how I can a) suppress the need for N's copy-constructor *and* b) have to_python conversions generated for the *HeldType*, i.e. 'Node *'. Can anybody help ? Thanks a lot ! Stefan From nico_ml at mgdesign.org Fri Mar 4 15:29:13 2005 From: nico_ml at mgdesign.org (Nicolas Lelong) Date: Fri, 4 Mar 2005 15:29:13 +0100 Subject: [C++-sig] class_, HeldType, and NonCopyable...please help !! References: <4227CAF6.3050100@sympatico.ca> Message-ID: <001501c520c6$89f622f0$de00a8c0@nico> Hi, off the top of my head, my answers may be wrong, here we go ! > class_ node("Node", no_init); fair enough, the noncopyable is OK, I'd rather let BPL decide the HeldType, so I'd use instead. class_ node("Node", no_init); > virtual void visit(Node* n) { call_method(self, "visit", n);} your problem, I believe (no time to check), is you call_method parameters. I think you have to let BPL know that you don't intend to copy the object by using boost::ref (at least it works for references, once more no time to check for pointers). So this would become : virtual void visit(Node* n) { call_method( self, "visit", boost::ref(n) ); } HTH & that i'm too wrong :P cheers, Nicolas. From seefeld at sympatico.ca Fri Mar 4 15:37:53 2005 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 04 Mar 2005 09:37:53 -0500 Subject: [C++-sig] class_, HeldType, and NonCopyable...please help !! In-Reply-To: <001501c520c6$89f622f0$de00a8c0@nico> References: <4227CAF6.3050100@sympatico.ca> <001501c520c6$89f622f0$de00a8c0@nico> Message-ID: <422872C1.80901@sympatico.ca> Nicolas Lelong wrote: > your problem, I believe (no time to check), is you call_method > parameters. I think you have to let BPL know that you don't intend to > copy the object by using boost::ref (at least it works for references, > once more no time to check for pointers). So this would become : > > virtual void visit(Node* n) { call_method( self, "visit", > boost::ref(n) ); } > > HTH & that i'm too wrong :P I think your suggestion is on-spot ! Having just browsed the various tests from the boost python library I experimented with bpl::ptr() and got it working, too. Thanks for your help ! Stefan From Jacques.Kerner at noos.fr Fri Mar 4 20:43:03 2005 From: Jacques.Kerner at noos.fr (Jacques Kerner) Date: Fri, 04 Mar 2005 20:43:03 +0100 Subject: [C++-sig] LinkLibraries Message-ID: <4228BA47.6020906@noos.fr> Hello, I am having a problem to link an extension module with bjam, which requires an external library. I get this : Unknown suffix on <@boost!libs!python!example!hlapython>. - see UserObject rule in Jamfile(5). Here is my Jamfile, very close to the basic example, with a added to it: # Specify our location in the boost project hierarchy subproject libs/python/example/hlapython ; # Include definitions needed for Python modules import python ; extension hlapython # Declare a Python extension called hlapython : HLAPython.cpp # source ../../build/boost_python # dependencies libFedTime libRTI-NG ; This is on Windows XP with Visual 7.1 (I don't think it is the problem). I don't understand how to link a library. I also tried : LinkLibrary hlapython : libFedTime libRTI-NG; but it does not work... Any help greatly appreciated. Best Regards, Jacques Kerner From rwgk at yahoo.com Tue Mar 8 15:39:28 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 8 Mar 2005 06:39:28 -0800 (PST) Subject: [C++-sig] 'numpy' test broken? Message-ID: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> > Hello, > using fresh CVS state, I get failure of the 'numpy' test. I run: > > bjam -sPYTHON_ROOT=/usr -sPYTHON_VERSION=2.3 numpy > > and get error. The interesting part of the test output is: I just checked in a workaround (numpy.py in test directory): # Unfortunately the doctest module works differently in Python versions # 2.2, 2.3, and 2.4. Newer versions evaluate all docstrings, even that # of objects with names starting with an underscore. To portably disable # tests based on the availability of Numeric and Numpy, the corresponding # test functions are simply deleted below if necessary. It is not a perfect fix since newer versions of Python's doctest module examine functions that we do not want to have examined, leading to spurious output, but that's all I have time for and the nasty long error messages are gone at least. Cheers, Ralf __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From paniq at paniq.org Tue Mar 8 17:07:41 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Tue, 08 Mar 2005 17:07:41 +0100 Subject: [C++-sig] test In-Reply-To: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> Message-ID: <422DCDCD.8090803@paniq.org> 1 2 testing testing. thank you, you may now proceed. there have been problems with subscribing to c++-sig with gmx.net because gmx doesnt think that ++ belongs into an email address, so this is a check whether everything is working fine before i start writing anything important ;) From seefeld at sympatico.ca Tue Mar 8 19:52:04 2005 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Tue, 08 Mar 2005 13:52:04 -0500 Subject: [C++-sig] bug: python.hpp not including python/make_constructor.hpp Message-ID: <422DF454.7050600@sympatico.ca> hi, as the subject suggests: including in my code isn't enough to be able to use 'boost::python::make_constructor()'. #include somewhere in boost/python.hpp should fix this. Thanks, Stefan From mb.ml.boost at adisoft-systems.de Wed Mar 9 17:44:32 2005 From: mb.ml.boost at adisoft-systems.de (Marco Borm) Date: Wed, 9 Mar 2005 17:44:32 +0100 Subject: [C++-sig] boost/python: how to: call memberfunctions of an existing c++ object from python? Message-ID: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> (I also posted this message to gmane.comp.lib.boost.devel) Hi Boost/Python developers, at first I have to say that I am no boost nor a python expert. I've searched for hours now on the web for my problem but was unable to find some solution for my problem: Currently I am working on the possibility that an python-script is called by an existing c++ object. This was "easy" to do with and without the boost python-classes. To make this more complicate, the script must be able to call some member functions of this object. So to make this possible I created an BOOST_PYTHON_MODULE() containing the class and the to be called member function-definitions. Now it is possible to create new instances of the class and call them from python. It is also possible to do the following in my c++ object-code: "ret = boost::python::call(PyFunction.ptr(), this );" But now my problem: boost copies the object and passes only that copy to the function. Is it and how is it possible to make the object accessible to the function within the python-script? I have found some hints in the boost-source for using smartptr but I was unable to use them as an parameter for call(): "TypeError: No to_python (by-value) converter found for C++ type: class boost::shared_ptr". I am also don't known if this is the right way to do. Thanks for help! Marco Borm From seefeld at sympatico.ca Wed Mar 9 17:52:55 2005 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Wed, 09 Mar 2005 11:52:55 -0500 Subject: [C++-sig] boost/python: how to: call memberfunctions of an existing c++ object from python? In-Reply-To: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> References: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> Message-ID: <422F29E7.2060202@sympatico.ca> Hi Marco, as I ran into a seemingly similar issue recently, I may be able to provide some help here. Marco Borm wrote: > Now it is possible to create new instances of the class and call them from > python. It is also possible to do the following in my c++ object-code: "ret > = boost::python::call(PyFunction.ptr(), this );" > > But now my problem: boost copies the object and passes only that copy to the > function. You may try to replace the call<> above by boost::python::call(PyFunction.ptr(), boost::python::ptr(this)); which instructs the bpl machinery to really expose 'this' as a reference, and not create a copy from it. HTH, Stefan From pierre.barbier at cirad.fr Wed Mar 9 18:08:43 2005 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Wed, 09 Mar 2005 18:08:43 +0100 Subject: [C++-sig] boost/python: how to: call memberfunctions of an existing c++ object from python? In-Reply-To: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> References: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> Message-ID: <422F2D9B.6010408@cirad.fr> If your C++ function takes as parameter a pointer or a reference on your object, then Boost won't copy it ! Then, if you want to use your own smart pointer to manage memory yourself (using shared_ptr for example), you will need to define the pointee template class partially specialized for your smart pointer (if your compiler allows this) and the get_pointer template function also. Pierre Marco Borm a ?crit : > (I also posted this message to gmane.comp.lib.boost.devel) > > Hi Boost/Python developers, > > at first I have to say that I am no boost nor a python expert. > I've searched for hours now on the web for my problem but was unable to find > some solution for my problem: > > Currently I am working on the possibility that an python-script is called by > an existing c++ object. This was "easy" to do with and without the boost > python-classes. > > To make this more complicate, the script must be able to call some member > functions of this object. > So to make this possible I created an BOOST_PYTHON_MODULE() containing the > class and the to be called member function-definitions. > Now it is possible to create new instances of the class and call them from > python. It is also possible to do the following in my c++ object-code: "ret > = boost::python::call(PyFunction.ptr(), this );" > > But now my problem: boost copies the object and passes only that copy to the > function. > Is it and how is it possible to make the object accessible to the function > within the python-script? > I have found some hints in the boost-source for using smartptr but I was > unable to use them as an parameter for call(): "TypeError: No to_python > (by-value) converter found for C++ type: class boost::shared_ptr". > I am also don't known if this is the right way to do. > > > Thanks for help! > Marco Borm > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68 From paniq at paniq.org Thu Mar 10 10:19:07 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Thu, 10 Mar 2005 10:19:07 +0100 Subject: [C++-sig] def with name parser In-Reply-To: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> References: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> Message-ID: <4230110B.8080003@paniq.org> hi everybody, as a lazy programmer, i found the def("name",&func) convention a bit uncomfortable, since often name and func are the same name, so why not allow an alternate version of def that parses the function name? there are several possibilities to do that, where the worst is #define def_autoname(func) def(parse(#func),&func) and a better one is #define def_autoname(func) def(parse(typeid(func).name()),&func) however i'm not a big fan of macros so i'd like to see this included natively in boost.python somewhere. is that possible, or do we run into cross platform issues with this? best regards, leonard From seefeld at sympatico.ca Thu Mar 10 14:47:48 2005 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu, 10 Mar 2005 08:47:48 -0500 Subject: [C++-sig] def with name parser In-Reply-To: <4230110B.8080003@paniq.org> References: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> <4230110B.8080003@paniq.org> Message-ID: <42305004.9020106@sympatico.ca> Leonard "paniq" Ritter wrote: > however i'm not a big fan of macros so i'd like to see this included > natively in boost.python somewhere. is that possible, or do we run into > cross platform issues with this? What you suggest is only possible with macros. And as I share with you my aversion to macros, especially if they aren't strictly necessary, I'd suggest not to include such a macro into boost.python :-) Keep in mind that the form 'def("foo", foo)' only works in the simplest of cases. Most of the time you have a combination of other things such as policies, class names, etc. to add, so a simple minded macro approach wouldn't work anyways. I don't think the small number of key strokes it may save you is worth the trouble. FWIW, Stefan From dave at boost-consulting.com Thu Mar 10 15:35:41 2005 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 10 Mar 2005 09:35:41 -0500 Subject: [C++-sig] Sorry for my absence Message-ID: Although I have been busy and didn't intend to be very active here, this list wasn't supposed to drop off my radar. But somehow the newsgroup got deleted from the list in my newsreader. Out of sight, out of mind, as they say. I'll be around, though of course I'm not going to participate in every thread ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Mar 10 15:38:33 2005 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 10 Mar 2005 09:38:33 -0500 Subject: [C++-sig] Re: boost/python: how to: call memberfunctions of an existing c++ object from python? References: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> <422F29E7.2060202@sympatico.ca> Message-ID: Stefan Seefeld writes: > Hi Marco, > > as I ran into a seemingly similar issue recently, I may be able to provide > some help here. > > Marco Borm wrote: > >> Now it is possible to create new instances of the class and call them from >> python. It is also possible to do the following in my c++ object-code: "ret >> = boost::python::call(PyFunction.ptr(), this );" >> But now my problem: boost copies the object and passes only that >> copy to the >> function. > > You may try to replace the call<> above by > > boost::python::call(PyFunction.ptr(), boost::python::ptr(this)); > > which instructs the bpl machinery to really expose 'this' as a reference, > and not create a copy from it. extract( PyFunction( boost::python:;ptr(this) ) ) should work. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Mar 10 15:39:51 2005 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 10 Mar 2005 09:39:51 -0500 Subject: [C++-sig] Re: bug: python.hpp not including python/make_constructor.hpp References: <422DF454.7050600@sympatico.ca> Message-ID: Stefan Seefeld writes: > hi, > > as the subject suggests: > > including in my code > isn't enough to be able to use 'boost::python::make_constructor()'. > > #include > > somewhere in boost/python.hpp should fix this. Fixed, thanks. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Mar 10 15:41:02 2005 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 10 Mar 2005 09:41:02 -0500 Subject: [C++-sig] Re: class_, HeldType, and NonCopyable...please help !! References: <4227CAF6.3050100@sympatico.ca> <001501c520c6$89f622f0$de00a8c0@nico> Message-ID: "Nicolas Lelong" writes: > Hi, > > off the top of my head, my answers may be wrong, here we go ! > >> class_ node("Node", no_init); > > fair enough, the noncopyable is OK, I'd rather let BPL decide the > HeldType, Uh, yeah. Using a raw pointer as the HeldType is playing with fire. -- Dave Abrahams Boost Consulting www.boost-consulting.com From seefeld at sympatico.ca Thu Mar 10 16:25:55 2005 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu, 10 Mar 2005 10:25:55 -0500 Subject: [C++-sig] Re: class_, HeldType, and NonCopyable...please help !! In-Reply-To: References: <4227CAF6.3050100@sympatico.ca> <001501c520c6$89f622f0$de00a8c0@nico> Message-ID: <42306703.1050602@sympatico.ca> Hi David, welcome back ! ;-) David Abrahams wrote: > Uh, yeah. Using a raw pointer as the HeldType is playing with fire. Do you have any suggestion as to how to deal with objects managed by a garbage collector (Boehm's) ? Is there any danger of the GC not seeing the python runtime referring to the objects ? I'm not sure I'm going to keep the GC in my code (I'm talking about the synopsis parse tree code, btw.), but for now it's there (legacy), and so I'd like to use it unchanged. Thanks, Stefan From dave at boost-consulting.com Thu Mar 10 17:01:40 2005 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 10 Mar 2005 11:01:40 -0500 Subject: [C++-sig] Re: class_, HeldType, and NonCopyable...please help !! References: <4227CAF6.3050100@sympatico.ca> <001501c520c6$89f622f0$de00a8c0@nico> <42306703.1050602@sympatico.ca> Message-ID: Stefan Seefeld writes: > Hi David, > > welcome back ! ;-) > > David Abrahams wrote: > >> Uh, yeah. Using a raw pointer as the HeldType is playing with fire. > > Do you have any suggestion as to how to deal with objects managed > by a garbage collector (Boehm's) ? Oh, in that case, it might be okay. > Is there any danger of the GC > not seeing the python runtime referring to the objects ? I don't see why there would be. > I'm not sure I'm going to keep the GC in my code (I'm talking about > the synopsis parse tree code, btw.), but for now it's there (legacy), > and so I'd like to use it unchanged. It seems like a good approach to that sort of data structure. -- Dave Abrahams Boost Consulting www.boost-consulting.com From paniq at paniq.org Thu Mar 10 20:18:44 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Thu, 10 Mar 2005 20:18:44 +0100 Subject: [C++-sig] def with name parser In-Reply-To: <42305004.9020106@sympatico.ca> References: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> <4230110B.8080003@paniq.org> <42305004.9020106@sympatico.ca> Message-ID: <42309D94.1020409@paniq.org> as far as i see, the second method is also possible as a template, and using overloads multiple versions of that def can be supported here's the simplest case, bit of pseudo template L& def_autoname(T func) { return def(parse(typeid(func).name()),func); } Stefan Seefeld wrote: > Leonard "paniq" Ritter wrote: > >> however i'm not a big fan of macros so i'd like to see this included >> natively in boost.python somewhere. is that possible, or do we run >> into cross platform issues with this? > > > What you suggest is only possible with macros. And as I share with you > my aversion to macros, especially if they aren't strictly necessary, I'd > suggest not to include such a macro into boost.python :-) > Keep in mind that the form 'def("foo", foo)' only works in the simplest > of cases. Most of the time you have a combination of other things such > as policies, class names, etc. to add, so a simple minded macro approach > wouldn't work anyways. > I don't think the small number of key strokes it may save you is worth > the trouble. > > FWIW, > Stefan > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > > From seefeld at sympatico.ca Thu Mar 10 20:49:50 2005 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu, 10 Mar 2005 14:49:50 -0500 Subject: [C++-sig] def with name parser In-Reply-To: <42309D94.1020409@paniq.org> References: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> <4230110B.8080003@paniq.org> <42305004.9020106@sympatico.ca> <42309D94.1020409@paniq.org> Message-ID: <4230A4DE.8020408@sympatico.ca> Leonard "paniq" Ritter wrote: > as far as i see, the second method is also possible as a template, and > using overloads multiple versions of that def can be supported > > here's the simplest case, bit of pseudo > > template > L& def_autoname(T func) > { > return def(parse(typeid(func).name()),func); > } There is no guarantee that typeid(func).name() == "func", with gcc it is not. It is mangled, and so not what you want. Stefan From dave at boost-consulting.com Thu Mar 10 21:26:39 2005 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 10 Mar 2005 15:26:39 -0500 Subject: [C++-sig] Re: def with name parser References: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> <4230110B.8080003@paniq.org> <42305004.9020106@sympatico.ca> <42309D94.1020409@paniq.org> <4230A4DE.8020408@sympatico.ca> Message-ID: Stefan Seefeld writes: > Leonard "paniq" Ritter wrote: >> as far as i see, the second method is also possible as a template, >> and using overloads multiple versions of that def can be supported >> here's the simplest case, bit of pseudo >> template >> L& def_autoname(T func) >> { >> return def(parse(typeid(func).name()),func); >> } > > There is no guarantee that typeid(func).name() == "func", with gcc it is not. > It is mangled, and so not what you want. Regardless, the function name has nothing to do with its type. int foo(); int bar(); assert(typeid(foo) == typeid(bar)); -- Dave Abrahams Boost Consulting www.boost-consulting.com From paniq at paniq.org Thu Mar 10 22:40:39 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Thu, 10 Mar 2005 22:40:39 +0100 Subject: [C++-sig] Re: def with name parser In-Reply-To: References: <20050309164431.F1FEE1410C@mail.adisoft-systems.de> <4230110B.8080003@paniq.org> <42305004.9020106@sympatico.ca> <42309D94.1020409@paniq.org> <4230A4DE.8020408@sympatico.ca> Message-ID: <4230BED7.6060006@paniq.org> argh, yes, crap. i dont know why i thought it would work. wish my favorite compiler flavor would offer a bit more reflection :) David Abrahams wrote: >Stefan Seefeld writes: > > > >>Leonard "paniq" Ritter wrote: >> >> >>>as far as i see, the second method is also possible as a template, >>>and using overloads multiple versions of that def can be supported >>>here's the simplest case, bit of pseudo >>>template >>>L& def_autoname(T func) >>>{ >>> return def(parse(typeid(func).name()),func); >>>} >>> >>> >>There is no guarantee that typeid(func).name() == "func", with gcc it is not. >>It is mangled, and so not what you want. >> >> > >Regardless, the function name has nothing to do with its type. > > int foo(); > int bar(); > assert(typeid(foo) == typeid(bar)); > > > From Mason.Christopher at mayo.edu Fri Mar 11 23:33:44 2005 From: Mason.Christopher at mayo.edu (Christopher Mason) Date: Fri, 11 Mar 2005 16:33:44 -0600 Subject: [C++-sig] Boost.Python: AllFromHeader Message-ID: Hello. Pyste is exceptionally cool. A quick question: AllFromHeader says: AllFromHeader is not working in all cases in the current version. (This is in boost_1_32_0.) Could someone please expound on this? Stay away completely? Use with caveats? I've noticed that things seem to not be in the right order (like Base->Derived dependencies). Is this part of the problem? Thanks, -c -- [ Christopher Mason MPRC Bioinformatics cjm37 at exrch.mayo.edu ] From dave at boost-consulting.com Sat Mar 12 02:00:08 2005 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 11 Mar 2005 20:00:08 -0500 Subject: [C++-sig] Sorry for my absence In-Reply-To: <20050312004809.GE28551@ewok.lucasdigital.com> (Nick Rasmussen's message of "Fri, 11 Mar 2005 16:48:09 -0800") References: <20050312004809.GE28551@ewok.lucasdigital.com> Message-ID: Nick Rasmussen writes: > In case you missed this thread: > > http://thread.gmane.org/gmane.comp.python.c++/7596 > > Do you have any opinion on this patch: > > http://article.gmane.org/gmane.comp.python.c%2B%2B/7633 Do all the Boost.Python tests pass? Are you certain it's okay to use PyCFunction_Type as a base class even though PyFunctionObject isn't layout-compatible with boost::python::objects::function? If you can answer yes to both of those questions, and explain your answer to the second one, then we can integrate your patch. -- Dave Abrahams Boost Consulting www.boost-consulting.com From nick at ilm.com Sat Mar 12 03:19:40 2005 From: nick at ilm.com (Nick Rasmussen) Date: Fri, 11 Mar 2005 18:19:40 -0800 Subject: [C++-sig] Sorry for my absence In-Reply-To: References: <20050312004809.GE28551@ewok.lucasdigital.com> Message-ID: <20050312021940.GG28551@ewok.lucasdigital.com> On Fri, 11 Mar 2005, David Abrahams wrote: > Nick Rasmussen writes: > > > In case you missed this thread: > > > > http://thread.gmane.org/gmane.comp.python.c++/7596 > > > > Do you have any opinion on this patch: > > > > http://article.gmane.org/gmane.comp.python.c%2B%2B/7633 > > Do all the Boost.Python tests pass? On linux-x86 with python 2.3 the regression tests pass. > Are you certain it's okay to use PyCFunction_Type as a base class even > though PyFunctionObject isn't layout-compatible with > boost::python::objects::function? > > If you can answer yes to both of those questions, and explain your > answer to the second one, then we can integrate your patch. The patch isn't using PyCFunction_Type as a base class, that was my original idea, and didn't work on all platforms: http://article.gmane.org/gmane.comp.python.c%2B%2B/7600 >From talking to the python-dev folks, it's unfortunately not intended to work in any currently released version of python. Given that there wasn't any way to make the right way work, there are three options that I came up with to make this work with existing python versions: 1: have end-users modify their installed inspect.py and/or pydoc.py files 2: replace inspect.isbuiltin dynamically on module load with a version that understands boost function types. 3: fool pydoc into thinking that boost::python functions are instances of the builtin function type. This patch attempts to solve the docstring problem via #3 since it seemed the least bad solution of the above three. That said, I'm by no means a python expert, and I don't know what all the ramifications are of overloading the __class__ attribute, I did it this way based on a suggestion from python- dev and it has worked for my needs, but it is definitely a kludge. -nick From dave at boost-consulting.com Sat Mar 12 03:59:45 2005 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 11 Mar 2005 21:59:45 -0500 Subject: [C++-sig] Sorry for my absence In-Reply-To: <20050312021940.GG28551@ewok.lucasdigital.com> (Nick Rasmussen's message of "Fri, 11 Mar 2005 18:19:40 -0800") References: <20050312004809.GE28551@ewok.lucasdigital.com> <20050312021940.GG28551@ewok.lucasdigital.com> Message-ID: Nick Rasmussen writes: > On Fri, 11 Mar 2005, David Abrahams wrote: > >> Nick Rasmussen writes: >> >> > In case you missed this thread: >> > >> > http://thread.gmane.org/gmane.comp.python.c++/7596 >> > >> > Do you have any opinion on this patch: >> > >> > http://article.gmane.org/gmane.comp.python.c%2B%2B/7633 >> >> Do all the Boost.Python tests pass? > > On linux-x86 with python 2.3 the regression tests pass. > >> Are you certain it's okay to use PyCFunction_Type as a base class even >> though PyFunctionObject isn't layout-compatible with >> boost::python::objects::function? >> >> If you can answer yes to both of those questions, and explain your >> answer to the second one, then we can integrate your patch. > > The patch isn't using PyCFunction_Type as a base class, that was > my original idea, and didn't work on all platforms: > > http://article.gmane.org/gmane.comp.python.c%2B%2B/7600 > >>From talking to the python-dev folks, it's unfortunately not intended > to work in any currently released version of python. > > Given that there wasn't any way to make the right way work, there > are three options that I came up with to make this work with existing > python versions: > > 1: have end-users modify their installed inspect.py and/or pydoc.py files > 2: replace inspect.isbuiltin dynamically on module load with a version > that understands boost function types. > 3: fool pydoc into thinking that boost::python functions are instances > of the builtin function type. > > This patch attempts to solve the docstring problem via #3 since it seemed > the least bad solution of the above three. That said, I'm by no means a > python expert, and I don't know what all the ramifications are of overloading > the __class__ attribute, I did it this way based on a suggestion from python- > dev and it has worked for my needs, but it is definitely a kludge. I applied it after fixing a few things: 0. Brace formatting convention 1. It does something tricky without any comments to explain what's happening!! 2. reinterpret_cast is nonportable and nearly always a no-no. Thanks for the patch. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Sat Mar 12 04:03:06 2005 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 11 Mar 2005 22:03:06 -0500 Subject: [C++-sig] Sorry for my absence In-Reply-To: (David Abrahams's message of "Fri, 11 Mar 2005 21:59:45 -0500") References: <20050312004809.GE28551@ewok.lucasdigital.com> <20050312021940.GG28551@ewok.lucasdigital.com> Message-ID: David Abrahams writes: >> This patch attempts to solve the docstring problem via #3 since it seemed >> the least bad solution of the above three. That said, I'm by no means a >> python expert, and I don't know what all the ramifications are of overloading >> the __class__ attribute, I did it this way based on a suggestion from python- >> dev and it has worked for my needs, but it is definitely a kludge. > > I applied it after fixing a few things: > > 0. Brace formatting convention > > 1. It does something tricky without any comments to explain what's > happening!! > > 2. reinterpret_cast is nonportable and nearly always a no-no. > > Thanks for the patch. Probably a better thing to do would be to fake the __class__ into being a dummy class derived from PyCFunction_Type, with a noticeably different name and a big ugly docstring explaining why it exists. That way anyone looking at the __class__ attribute will have a clue what's going on. If you could make that patch, I'd appreciate it. -- Dave Abrahams Boost Consulting www.boost-consulting.com From jbrandmeyer at earthlink.net Sat Mar 12 06:13:22 2005 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Sat, 12 Mar 2005 00:13:22 -0500 Subject: [C++-sig] Sorry for my absence In-Reply-To: <20050312021940.GG28551@ewok.lucasdigital.com> References: <20050312004809.GE28551@ewok.lucasdigital.com> <20050312021940.GG28551@ewok.lucasdigital.com> Message-ID: <1110604402.30511.3.camel@illuvatar> On Fri, 2005-03-11 at 18:19 -0800, Nick Rasmussen wrote: > Given that there wasn't any way to make the right way work, there > are three options that I came up with to make this work with existing > python versions: > > 1: have end-users modify their installed inspect.py and/or pydoc.py files > 2: replace inspect.isbuiltin dynamically on module load with a version > that understands boost function types. > 3: fool pydoc into thinking that boost::python functions are instances > of the builtin function type. There is another option that I haven't had time to fully explore - make inspect.getmodule() work for a free Boost.Python.function. I think that if the code that makes Boost.Python.class objects' __module__ member work was applied to free function objects, a trivial change could be made to inspect.getmodule(). -Jonathan From paniq at paniq.org Sat Mar 12 19:18:15 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Sat, 12 Mar 2005 19:18:15 +0100 Subject: [C++-sig] submodules In-Reply-To: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> Message-ID: <42333267.1050604@paniq.org> in search of whether i could implement submodules in one .pyd using boost.python i found some old posts on the c++ sig that conclude with "well, it currently does not work" is this still true? From paniq at paniq.org Sat Mar 12 21:01:23 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Sat, 12 Mar 2005 21:01:23 +0100 Subject: [C++-sig] fup: submodules (oops) In-Reply-To: <42333267.1050604@paniq.org> References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <42333267.1050604@paniq.org> Message-ID: <42334A93.2000600@paniq.org> despite being a regular visitor of the faq i simply overlooked the manual given there. do not reply ;) Leonard "paniq" Ritter wrote: > in search of whether i could implement submodules in one .pyd using > boost.python i found some old posts on the c++ sig that conclude with > "well, it currently does not work" > > is this still true? > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > > From paniq at paniq.org Sat Mar 12 21:12:02 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Sat, 12 Mar 2005 21:12:02 +0100 Subject: [C++-sig] exporting __stdcall methods In-Reply-To: <422DCDCD.8090803@paniq.org> References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> Message-ID: <42334D12.2020608@paniq.org> i'm currently running into an issue with exporting interface methods that have been declared as __stdcall. i found two mails relating to that issue, http://mail.python.org/pipermail/c++-sig/2005-February/008556.html and http://mail.python.org/pipermail/c++-sig/2003-April/003811.html has a solution been found for this yet? is there a standard solution for that problem? i have no chance of changing the calling convention. best regards, leonard From dave at boost-consulting.com Sat Mar 12 21:44:04 2005 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 12 Mar 2005 15:44:04 -0500 Subject: [C++-sig] Re: exporting __stdcall methods References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> Message-ID: "Leonard \"paniq\" Ritter" writes: > http://mail.python.org/pipermail/c++-sig/2005-February/008556.html > > and > > http://mail.python.org/pipermail/c++-sig/2003-April/003811.html > > has a solution been found for this yet? > > is there a standard solution for that problem? i have no chance of > changing the calling convention. The solution is fairly well-known, but may require large-scale hacking at Boost.Python. It needs a great many overloads added. I don't think I can find the time for it right now; maybe someone else can do it. -- Dave Abrahams Boost Consulting www.boost-consulting.com From paniq at paniq.org Sat Mar 12 23:02:19 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Sat, 12 Mar 2005 23:02:19 +0100 Subject: [C++-sig] operator ->, cast operator In-Reply-To: References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> Message-ID: <423366EB.4070308@paniq.org> i see there are easy methods of exporting operators that deal with values and mathematical operations, but is there any chance of exporting pointer-to operators? in this particular case i am exporting a custom interface pointer class to python. in c++ i can use such a smart pointer like this: Ptr view(L"?.Sandoz.View"); if (view) { view->Attach(hWnd, true); ... where Ptr exposes its member T _object using InterfaceType* operator->() { return _object; } i'm exposing Ptr as "View" and the View interface as "ViewInterface" to python. what i'd like to write in python would be something along the lines of view = View("?.Sandoz.View") view.Attach(self.window, true) can i realize this without much trouble? From mike at thewilsonfamily.freeserve.co.uk Sat Mar 12 23:02:10 2005 From: mike at thewilsonfamily.freeserve.co.uk (Mike) Date: Sat, 12 Mar 2005 22:02:10 -0000 Subject: [C++-sig] Problem in 1.32 in 'boost::python::range' (works in 1.31) Message-ID: <001501c5274f$392bd240$37ce4e51@MIKESPC01> The attached code with error message is a simplified version of code that compiles in MSVC 7.1, boost_1_31, but fails to compile in 1_32. This post is based on one I sent nearly a month ago. My apologies for re-sending it, but when I saw that maybe David Abrahams had missed some, I'd thought I'd try again. Please excuse me David if you have in fact already read it. Regards, Mike -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: FailsIn1_32.cpp URL: From dave at boost-consulting.com Sat Mar 12 23:46:30 2005 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 12 Mar 2005 17:46:30 -0500 Subject: [C++-sig] Re: operator ->, cast operator References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <423366EB.4070308@paniq.org> Message-ID: "Leonard \"paniq\" Ritter" writes: > i see there are easy methods of exporting operators that deal with > values and mathematical operations, but is there any chance of exporting > pointer-to operators? > > in this particular case i am exporting a custom interface pointer class > to python. > > in c++ i can use such a smart pointer like this: > > Ptr view(L"?.Sandoz.View"); > if (view) > { > view->Attach(hWnd, true); > > ... > > where Ptr exposes its member T _object using > > InterfaceType* operator->() > { > return _object; > } > > i'm exposing Ptr as "View" and the View interface as > "ViewInterface" to python. > > what i'd like to write in python would be something along the lines of > > view = View("?.Sandoz.View") > view.Attach(self.window, true) > > can i realize this without much trouble? Yeah, just export View using Ptr as the HeldType. -- Dave Abrahams Boost Consulting www.boost-consulting.com From paniq at paniq.org Sun Mar 13 00:10:39 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Sun, 13 Mar 2005 00:10:39 +0100 Subject: [C++-sig] Re: operator ->, cast operator In-Reply-To: References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <423366EB.4070308@paniq.org> Message-ID: <423376EF.3010309@paniq.org> >Yeah, just export View using Ptr as the HeldType. > > as if it were that easy! ;) i followed the manual for that and exposed Ptr as a pointee using namespace boost { namespace python { template struct pointee< Mu::Ptr > { typedef T type; }; } } in a macro that exposes the class to python, class_ is instantiated like this class_, Ptr, boost::noncopyable > exportedClass(interfaceName, no_init) where ClassType is an interface class. the compiler gives me: p:\MuFramework\Shared\Code\boost\boost\python\object\make_ptr_instance.hpp(30) : error C2784: 'T *boost::python::get_pointer(const boost::python::handle &)' : could not deduce template argument for 'const boost::python::handle &' from 'const boost::python::objects::class_metadata::held_type' with [ T=ClassType, X1=boost::python::bases, X2=Mu::Ptr, X3=boost::noncopyable ] p:\MuFramework\Shared\Code\boost\boost\python\handle.hpp(143) : see declaration of 'boost::python::get_pointer' p:\MuFramework\Shared\Code\boost\boost\python\object\make_instance.hpp(26) : see reference to function template instantiation 'PyTypeObject *boost::python::objects::make_ptr_instance::get_class_object(const Ptr &)' being compiled with [ T=ClassType, Holder=boost::python::objects::pointer_holder,Mu::Ptr,boost::noncopyable>::held_type,ClassType>, Arg=boost::python::objects::class_metadata,Mu::Ptr,boost::noncopyable>::held_type, Ptr=boost::python::objects::class_metadata,Mu::Ptr,boost::noncopyable>::held_type ] p:\MuFramework\Shared\Code\boost\boost\python\object\class_wrapper.hpp(36) : see reference to function template instantiation 'PyObject *boost::python::objects::make_instance_impl::execute(Arg &)' being compiled with [ T=ClassType, Holder=boost::python::objects::pointer_holder,Mu::Ptr,boost::noncopyable>::held_type,ClassType>, Derived=boost::python::objects::make_ptr_instance,Mu::Ptr,boost::noncopyable>::held_type,ClassType>>, Src=boost::python::objects::class_metadata,Mu::Ptr,boost::noncopyable>::held_type, Arg=boost::python::objects::class_metadata,Mu::Ptr,boost::noncopyable>::held_type ] p:\MuFramework\Shared\Code\boost\boost\python\object\class_wrapper.hpp(35) : while compiling class-template member function 'PyObject *boost::python::objects::class_value_wrapper::convert(Src)' with [ Src=boost::python::objects::class_metadata,Mu::Ptr,boost::noncopyable>::held_type, MakeInstance=boost::python::objects::make_ptr_instance,Mu::Ptr,boost::noncopyable>::held_type,ClassType>> ] p:\MuFramework\Shared\Code\boost\boost\python\object\class_metadata.hpp(237) : see reference to class template instantiation 'boost::python::objects::class_value_wrapper' being compiled with [ Src=boost::python::objects::class_metadata,Mu::Ptr,boost::noncopyable>::held_type, MakeInstance=boost::python::objects::make_ptr_instance,Mu::Ptr,boost::noncopyable>::held_type,ClassType>> ] p:\MuFramework\Shared\Code\boost\boost\python\object\class_metadata.hpp(221) : see reference to function template instantiation 'void boost::python::objects::class_metadata::maybe_register_pointer_to_python(T2 *,boost::mpl::false_ *,boost::mpl::false_ *)' being compiled with [ T=ClassType, X1=boost::python::bases, X2=Mu::Ptr, X3=boost::noncopyable, T2=ClassType ] p:\MuFramework\Shared\Code\boost\boost\python\object\class_metadata.hpp(208) : see reference to function template instantiation 'void boost::python::objects::class_metadata::register_aux2>(T2 *,Callback)' being compiled with [ T=ClassType, X1=boost::python::bases, X2=Mu::Ptr, X3=boost::noncopyable, C_=false, T2=ClassType, Callback=boost::mpl::bool_ ] p:\MuFramework\Shared\Code\boost\boost\python\object\class_metadata.hpp(206) : while compiling class-template member function 'void boost::python::objects::class_metadata::register_aux(void *)' with [ T=ClassType, X1=boost::python::bases, X2=Mu::Ptr, X3=boost::noncopyable ] p:\MuFramework\Shared\Code\boost\boost\python\class.hpp(174) : see reference to class template instantiation 'boost::python::objects::class_metadata' being compiled with [ T=ClassType, X1=boost::python::bases, X2=Mu::Ptr, X3=boost::noncopyable ] p:\MuFramework\Shared\Code\boost\boost\python\class.hpp(592) : see reference to class template instantiation 'boost::python::class_::id_vector' being compiled with [ W=ClassType, X1=boost::python::bases, X2=Mu::Ptr, X3=boost::noncopyable ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\deque(19) : while compiling class-template member function 'boost::python::class_::class_(const char *,boost::python::no_init_t)' with [ W=ClassType, X1=boost::python::bases, X2=Mu::Ptr, X3=boost::noncopyable ] p:\MuFramework\Libraries\MuPython\MuPython.Sandoz.h(37) : see reference to class template instantiation 'boost::python::class_' being compiled with [ W=ClassType, X1=boost::python::bases, X2=Mu::Ptr, X3=boost::noncopyable ] any idea? From dave at boost-consulting.com Sun Mar 13 00:09:45 2005 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 12 Mar 2005 18:09:45 -0500 Subject: [C++-sig] Re: Problem in 1.32 in 'boost::python::range' (works in 1.31) References: <001501c5274f$392bd240$37ce4e51@MIKESPC01> Message-ID: "Mike" writes: > The attached code with error message is a simplified version of code that > compiles in MSVC 7.1, boost_1_31, but fails to compile in 1_32. > > This post is based on one I sent nearly a month ago. My apologies for > re-sending it, but when I saw that maybe David Abrahams had missed some, I'd > thought I'd try again. > Please excuse me David if you have in fact already read it. Try the following patch to boost/iterator/iterator_facade.hpp, which I've checked into CVS -------------- next part -------------- A non-text attachment was scrubbed... Name: iterator_facade.hpp Type: text/x-cplusplus Size: 29097 bytes Desc: not available URL: -------------- next part -------------- -- Dave Abrahams Boost Consulting www.boost-consulting.com From mike at thewilsonfamily.freeserve.co.uk Sun Mar 13 00:18:45 2005 From: mike at thewilsonfamily.freeserve.co.uk (Mike) Date: Sat, 12 Mar 2005 23:18:45 -0000 Subject: [C++-sig] exporting __stdcall methods References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com><422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> Message-ID: <005101c52759$ee9cc030$37ce4e51@MIKESPC01> Here's my quick fix, but as I couldn't make it work for member functions I can't be sure its right (but it does compile & run my simple test case). In python/signature.hpp, add the following just after the first definition of the template function get_signature Its an exact copy of the first get_signature function , except for the "__stdcall" addition. template < class RT BOOST_PP_ENUM_TRAILING_PARAMS_Z(1, N, class T)> inline BOOST_PYTHON_LIST_INC(N)< RT BOOST_PP_ENUM_TRAILING_PARAMS_Z(1, N, T)> get_signature(RT(__stdcall * )(BOOST_PP_ENUM_PARAMS_Z(1, N, T)), void* = 0) { return BOOST_PYTHON_LIST_INC(N)< RT BOOST_PP_ENUM_TRAILING_PARAMS_Z(1, N, T) >(); } I tried in a similar vain for the 2 member functions variants that appear later in the same file. However, I had no success, hence the reason for my caution. Regards, Mike ----- Original Message ----- From: "Leonard "paniq" Ritter" To: "Development of Python/C++ integration" Sent: Saturday, March 12, 2005 8:12 PM Subject: [C++-sig] exporting __stdcall methods > i'm currently running into an issue with exporting interface methods > that have been declared as __stdcall. > > i found two mails relating to that issue, > > http://mail.python.org/pipermail/c++-sig/2005-February/008556.html > > and > > http://mail.python.org/pipermail/c++-sig/2003-April/003811.html > > has a solution been found for this yet? > > is there a standard solution for that problem? i have no chance of > changing the calling convention. > > best regards, > leonard > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From paniq at paniq.org Sun Mar 13 00:38:22 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Sun, 13 Mar 2005 00:38:22 +0100 Subject: [C++-sig] exporting __stdcall methods In-Reply-To: <005101c52759$ee9cc030$37ce4e51@MIKESPC01> References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com><422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <005101c52759$ee9cc030$37ce4e51@MIKESPC01> Message-ID: <42337D6E.2010505@paniq.org> >I tried in a similar vain for the 2 member functions variants that appear >later in the same file. >However, I had no success, hence the reason for my caution. > > > yes, it works for functions but not for methods. when adding something similar for __stdcall i get boost\python\detail\invoke.hpp(75) : error C2064: term does not evaluate to a function taking 2 arguments where my confusion does not permit me to make anymore assumptions on how to fix this ;) From dave at boost-consulting.com Sun Mar 13 00:38:37 2005 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 12 Mar 2005 18:38:37 -0500 Subject: [C++-sig] Re: operator ->, cast operator References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <423366EB.4070308@paniq.org> <423376EF.3010309@paniq.org> Message-ID: "Leonard \"paniq\" Ritter" writes: >>Yeah, just export View using Ptr as the HeldType. >> >> > as if it were that easy! ;) > > i followed the manual for that and exposed Ptr as a pointee using > > namespace boost > { > namespace python > { > template > struct pointee< Mu::Ptr > > { > typedef T type; > }; > } > } You also need namespace Mu { template T* get_pointer(Ptr const& p) { return p.get(); // or something } } -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Sun Mar 13 00:47:12 2005 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 12 Mar 2005 18:47:12 -0500 Subject: [C++-sig] Re: exporting __stdcall methods References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <005101c52759$ee9cc030$37ce4e51@MIKESPC01> <42337D6E.2010505@paniq.org> Message-ID: "Leonard \"paniq\" Ritter" writes: >>I tried in a similar vain for the 2 member functions variants that appear >>later in the same file. >>However, I had no success, hence the reason for my caution. >> >> >> > > yes, it works for functions but not for methods. when adding something > similar for __stdcall i get > > boost\python\detail\invoke.hpp(75) : error C2064: term does not evaluate > to a function taking 2 arguments > > where my confusion does not permit me to make anymore assumptions on how > to fix this ;) Files like boost/type_traits/detail/is_mem_fun_pointer_tester.hpp which are outside the Boost.Python library would need to be enhanced to deal with __stdcall, etc. -- Dave Abrahams Boost Consulting www.boost-consulting.com From paniq at paniq.org Sun Mar 13 00:55:22 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Sun, 13 Mar 2005 00:55:22 +0100 Subject: [C++-sig] Re: operator ->, cast operator In-Reply-To: References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <423366EB.4070308@paniq.org> <423376EF.3010309@paniq.org> Message-ID: <4233816A.4080107@paniq.org> >You also need > >namespace Mu >{ > template > T* get_pointer(Ptr const& p) > { > return p.get(); // or something > } >} > > > in my case GetObject() which needed to be const. assuming the problem was that i have not defined const cast operators i declared various flavors of cast operators in Ptr<>, but without luck. only adding get_pointer would make it work. is the requirement of get_pointer somewhere mentioned in the documentation? i was unable to find it. From paniq at paniq.org Sun Mar 13 01:02:56 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Sun, 13 Mar 2005 01:02:56 +0100 Subject: [C++-sig] Re: operator ->, cast operator In-Reply-To: References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <423366EB.4070308@paniq.org> <423376EF.3010309@paniq.org> Message-ID: <42338330.3090608@paniq.org> appending i should say that the code compiled, but i still had no access on View's methods. i modified the code so that the export of Ptr<> was removed (i assume it was not needed anymore), and so i'm left with an abstract class export with a custom smart pointer that doesnt give me any benefit because i dont have access to the smart pointers constructor (which a shortcut to looking up the library from the class id, loading it, resolving the factory function and obtaining a new object) - that means using Ptr<> as HeldType does not seem to let me use the interface instantiations in the fashion i wanted to from python. given that Ptr<> itself exports a few nice methods i want to use from python (such as factory constructors and interface querying methods), is there any chance of exposing these? >You also need > >namespace Mu >{ > template > T* get_pointer(Ptr const& p) > { > return p.get(); // or something > } >} > > > > From mike at thewilsonfamily.freeserve.co.uk Sun Mar 13 01:11:42 2005 From: mike at thewilsonfamily.freeserve.co.uk (Mike) Date: Sun, 13 Mar 2005 00:11:42 -0000 Subject: [C++-sig] Re: Problem in 1.32 in 'boost::python::range' (works in1.31) References: <001501c5274f$392bd240$37ce4e51@MIKESPC01> Message-ID: <00bb01c52761$3d764800$37ce4e51@MIKESPC01> Both the simple example and the code it was based on now work, thank you. Mike ----- Original Message ----- From: "David Abrahams" To: Sent: Saturday, March 12, 2005 11:09 PM Subject: [C++-sig] Re: Problem in 1.32 in 'boost::python::range' (works in1.31) > "Mike" writes: > > > The attached code with error message is a simplified version of code that > > compiles in MSVC 7.1, boost_1_31, but fails to compile in 1_32. > > > > This post is based on one I sent nearly a month ago. My apologies for > > re-sending it, but when I saw that maybe David Abrahams had missed some, I'd > > thought I'd try again. > > Please excuse me David if you have in fact already read it. > > Try the following patch to boost/iterator/iterator_facade.hpp, which > I've checked into CVS > > From paniq at paniq.org Sun Mar 13 01:17:54 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Sun, 13 Mar 2005 01:17:54 +0100 Subject: [C++-sig] Re: operator ->, cast operator In-Reply-To: <42338330.3090608@paniq.org> References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <423366EB.4070308@paniq.org> <423376EF.3010309@paniq.org> <42338330.3090608@paniq.org> Message-ID: <423386B2.6090203@paniq.org> followup (heh): to get the syntax i wished for i wrote a function that went like template Ptr New(const String& objectClassName) { return Ptr(objectClassName); } and exposed it via def("View",New), and that works due to boost.pythons magical ptr conversion wizardry ;) the class itself is now exposed as "ViewInterface" which is not _perfect_, but its sufficient since type names dont play a big role in python anyway. thank you dave for the help, boost.python rocks again :) Leonard "paniq" Ritter wrote: > > appending i should say that the code compiled, but i still had no > access on View's methods. i modified the code so that the export of > Ptr<> was removed (i assume it was not needed anymore), and so i'm > left with an abstract class export with a custom smart pointer that > doesnt give me any benefit because i dont have access to the smart > pointers constructor (which a shortcut to looking up the library from > the class id, loading it, resolving the factory function and obtaining > a new object) - that means using Ptr<> as HeldType does not seem to > let me use the interface instantiations in the fashion i wanted to > from python. > > given that Ptr<> itself exports a few nice methods i want to use from > python (such as factory constructors and interface querying methods), > is there any chance of exposing these? > >> You also need >> namespace Mu >> { >> template >> T* get_pointer(Ptr const& p) >> { return p.get(); // or something >> } >> } >> >> >> >> > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > > From dave at boost-consulting.com Sun Mar 13 01:17:25 2005 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 12 Mar 2005 19:17:25 -0500 Subject: [C++-sig] Re: operator ->, cast operator References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <423366EB.4070308@paniq.org> <423376EF.3010309@paniq.org> <42338330.3090608@paniq.org> Message-ID: "Leonard \"paniq\" Ritter" writes: > appending i should say that the code compiled, but i still had no access > on View's methods. i modified the code so that the export of Ptr<> was > removed (i assume it was not needed anymore), and so i'm left with an > abstract class export with a custom smart pointer that doesnt give me > any benefit because i dont have access to the smart pointers > constructor Use make_constructor to register the constructor for the smart pointer in the View export. > (which a shortcut to looking up the library from the class id, loading > it, resolving the factory function and obtaining a new object) - that > means using Ptr<> as HeldType does not seem to let me use the interface > instantiations in the fashion i wanted to from python. > > given that Ptr<> itself exports a few nice methods i want to use from > python (such as factory constructors and interface querying methods), is > there any chance of exposing these? Sure; just make thin wrapper functions that take a Ptr& as the first argument and then def them. In fact, I don't think you need the thin wrappers and you can just .def("foo", &Ptr::foo) in your class_ construct. -- Dave Abrahams Boost Consulting www.boost-consulting.com From paniq at paniq.org Sun Mar 13 01:51:03 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Sun, 13 Mar 2005 01:51:03 +0100 Subject: [C++-sig] Re: operator ->, cast operator In-Reply-To: References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <423366EB.4070308@paniq.org> <423376EF.3010309@paniq.org> <42338330.3090608@paniq.org> Message-ID: <42338E77.8090208@paniq.org> >Use make_constructor to register the constructor for the smart pointer >in the View export. > > exportedClass.def("__init__",make_constructor(New)); did it, rox. thanks again! this gives me plenty of ideas to solve other comfortability-issues as well. :) >Sure; just make thin wrapper functions that take a Ptr& as the >first argument and then def them. In fact, I don't think you need the >thin wrappers and you can just > > .def("foo", &Ptr::foo) > >in your class_ construct. > > will try that when time comes and give feedback From dave at boost-consulting.com Sun Mar 13 01:14:31 2005 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 12 Mar 2005 19:14:31 -0500 Subject: [C++-sig] Re: operator ->, cast operator References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <423366EB.4070308@paniq.org> <423376EF.3010309@paniq.org> <4233816A.4080107@paniq.org> Message-ID: "Leonard \"paniq\" Ritter" writes: >> You also need >> >>namespace Mu >>{ >> template >> T* get_pointer(Ptr const& p) >> { return p.get(); // or something >> } >>} >> >> >> > in my case GetObject() which needed to be const. assuming the problem > was that i have not defined const cast operators i declared various > flavors of cast operators in Ptr<>, but without luck. only adding > get_pointer would make it work. > > is the requirement of get_pointer somewhere mentioned in the > documentation? i was unable to find it. It's in the description of the Dereferenceable concept, which is referenced in the place where you found a reference to pointee<>. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Sun Mar 13 01:21:10 2005 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 12 Mar 2005 19:21:10 -0500 Subject: [C++-sig] Re: operator ->, cast operator References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <423366EB.4070308@paniq.org> <423376EF.3010309@paniq.org> <42338330.3090608@paniq.org> <423386B2.6090203@paniq.org> Message-ID: "Leonard \"paniq\" Ritter" writes: > followup (heh): > > to get the syntax i wished for i wrote a function that went like > > template > Ptr New(const String& objectClassName) > { > return Ptr(objectClassName); > } > > and exposed it via def("View",New), and that works due to > boost.pythons magical ptr conversion wizardry ;) the class itself is now > exposed as "ViewInterface" which is not _perfect_, but its sufficient > since type names dont play a big role in python anyway. Okay, but you could use make_constructor; it will get you the interface you want. > thank you dave for the help, boost.python rocks again :) Sure. -- Dave Abrahams Boost Consulting www.boost-consulting.com From spgroups at gmail.com Sun Mar 13 17:36:35 2005 From: spgroups at gmail.com (Satendra Pratap) Date: Sun, 13 Mar 2005 08:36:35 -0800 Subject: [C++-sig] urgent!! Message-ID: <47f703220503130836698d2d3c@mail.gmail.com> Hi 2 all, Can this group help me in implementing a new C++ library for Sparc Architecture for Nucleus RTOS... Plz reply soon... Thankyou in Advance.... Satendra... From jlh at yvn.com Mon Mar 14 05:53:46 2005 From: jlh at yvn.com (jim) Date: Mon, 14 Mar 2005 04:53:46 +0000 Subject: [C++-sig] xbase-2.0.0 bindings for python Message-ID: <200503140453.46973.jlh@yvn.com> Sirs: I have bindings for the xbase2.0.0 c++ library with the sip files and a wrapper class in python available if anyone is interested. I would appreciate suggestions for where and how to let folks know that this is available if this isn't the proper format and forum. Jim Hurlburt Yakima, WA From yangbing at kingsoft.com Mon Mar 14 07:30:16 2005 From: yangbing at kingsoft.com (Ñî±ù[Ô´´úÂëÖ®¹â]) Date: Mon, 14 Mar 2005 14:30:16 +0800 Subject: [C++-sig] how to access live c++ object? Message-ID: This is my class class CT { public: CT() {}; ~CT() {}; int GetNum( void ) { return num; } void SetNum( int n ) { num = n; } private: int num; }; static CT ct; CT & getCT( void ) { return ct; } I want to access ct object from boost.python, thanks for your advice. From paniq at paniq.org Mon Mar 14 09:45:51 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Mon, 14 Mar 2005 09:45:51 +0100 Subject: [C++-sig] how to access live c++ object? In-Reply-To: References: Message-ID: <42354F3F.5070406@paniq.org> ... def("getCT",&getCT,return_value_policy()); ... ????[??????????] wrote: >This is my class >class CT >{ >public: > CT() {}; > ~CT() {}; > int GetNum( void ) { return num; } > void SetNum( int n ) { num = n; } > >private: > int num; >}; > >static CT ct; > >CT & getCT( void ) >{ > return ct; >} > >I want to access ct object from boost.python, thanks for your advice. > > > >_______________________________________________ >C++-sig mailing list >C++-sig at python.org >http://mail.python.org/mailman/listinfo/c++-sig > > > > From nick at ilm.com Mon Mar 14 18:09:55 2005 From: nick at ilm.com (Nick Rasmussen) Date: Mon, 14 Mar 2005 09:09:55 -0800 Subject: [C++-sig] Sorry for my absence In-Reply-To: References: <20050312004809.GE28551@ewok.lucasdigital.com> <20050312021940.GG28551@ewok.lucasdigital.com> Message-ID: <20050314170955.GH28551@ewok.lucasdigital.com> On Fri, 11 Mar 2005, David Abrahams wrote: > David Abrahams writes: > > Probably a better thing to do would be to fake the __class__ into > being a dummy class derived from PyCFunction_Type, with a noticeably > different name and a big ugly docstring explaining why it exists. > That way anyone looking at the __class__ attribute will have a clue > what's going on. If you could make that patch, I'd appreciate it. I don't think that's possible, for the same reason we can't inherit from it for the boost function objects. Trying it out in the interpreter, I got: >>> import types >>> class Foo(types.BuiltinFunctionType): ... '''subclass of BuiltinFunctionType''' ... Traceback (most recent call last): File "", line 1, in ? TypeError: type 'builtin_function_or_method' is not an acceptable base type -nick From dave at stlport.com Mon Mar 14 18:22:26 2005 From: dave at stlport.com (Dave Abrahams) Date: Mon, 14 Mar 2005 12:22:26 -0500 Subject: [C++-sig] Sorry for my absence In-Reply-To: <20050314170955.GH28551@ewok.lucasdigital.com> References: <20050312004809.GE28551@ewok.lucasdigital.com> <20050312021940.GG28551@ewok.lucasdigital.com> <20050314170955.GH28551@ewok.lucasdigital.com> Message-ID: On Mon, 14 Mar 2005 09:09:55 -0800 Nick Rasmussen wrote: > On Fri, 11 Mar 2005, David Abrahams wrote: > >> David Abrahams writes: >> >> Probably a better thing to do would be to fake the >>__class__ into >> being a dummy class derived from PyCFunction_Type, with >>a noticeably >> different name and a big ugly docstring explaining why >>it exists. >> That way anyone looking at the __class__ attribute will >>have a clue >> what's going on. If you could make that patch, I'd >>appreciate it. > > I don't think that's possible, for the same reason we >can't inherit > from it for the boost function objects. Trying it out >in the > interpreter, I got: > >>>> import types >>>> class Foo(types.BuiltinFunctionType): > ... '''subclass of BuiltinFunctionType''' > ... > Traceback (most recent call last): > File "", line 1, in ? > TypeError: type 'builtin_function_or_method' is not an >acceptable base type Understood, thanks. From abentley at panoramicfeedback.com Mon Mar 14 18:02:41 2005 From: abentley at panoramicfeedback.com (Aaron Bentley) Date: Mon, 14 Mar 2005 12:02:41 -0500 Subject: [C++-sig] Problems with dynamic casts Message-ID: Hi, I'm having a problem with dynamic casting on an object constructed using Python. It seems as though the type of an owned object is being lost. I have a test as follows: assert (dynamic_cast(loc.getElement(elists[0])) !=NULL); When I invoke it from the constructor of the owning object (the object that owns elists), the test passes. But when I construct the owning object and then invoke the test through Python, it fails. I'm using gcc 3.0.4 from Debian stable. This looks ugly to me. So far the only explanation I've been able to come up with is memory corruption. Aaron -- Aaron Bentley Director of Technology Panometrics, Inc. From nick at ilm.com Mon Mar 14 19:37:13 2005 From: nick at ilm.com (Nick Rasmussen) Date: Mon, 14 Mar 2005 10:37:13 -0800 Subject: [C++-sig] Sorry for my absence In-Reply-To: <1110604402.30511.3.camel@illuvatar> References: <20050312004809.GE28551@ewok.lucasdigital.com> <20050312021940.GG28551@ewok.lucasdigital.com> <1110604402.30511.3.camel@illuvatar> Message-ID: <20050314183713.GJ28551@ewok.lucasdigital.com> On Sat, 12 Mar 2005, Jonathan Brandmeyer wrote: > On Fri, 2005-03-11 at 18:19 -0800, Nick Rasmussen wrote: > > Given that there wasn't any way to make the right way work, there > > are three options that I came up with to make this work with existing > > python versions: > > > > 1: have end-users modify their installed inspect.py and/or pydoc.py files > > 2: replace inspect.isbuiltin dynamically on module load with a version > > that understands boost function types. > > 3: fool pydoc into thinking that boost::python functions are instances > > of the builtin function type. > > There is another option that I haven't had time to fully explore - make > inspect.getmodule() work for a free Boost.Python.function. I think that > if the code that makes Boost.Python.class objects' __module__ member > work was applied to free function objects, a trivial change could be > made to inspect.getmodule(). I thought about that as well, but here's what I came up with, given the premise that we don't want to do #1 or #2 above: I checked the rest of the types that show up in inspect.getfile that we could possibly use to fake out the existing code: FunctionType, CodeType, FrameType, MethodType, aren't subclassable. ModuleType is, but that doesn't seem like a good candidate to subclass, since pydoc will ignore the function again. ClassType isn't subclassable, however inspect.isclass has an extra case that doesn't show up in the other is* functions: hasattr(object,'__bases__') If we add a __bases__ attribute to the function objects, inspect.isclass will think its a class, and then if we stash a pointer to the module in __module__ the lookup would work properly. Unfortunately, if inspect.isclass reports the function as a class, pydoc tries to document it as such :/ -nick From dave at boost-consulting.com Mon Mar 14 19:21:40 2005 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 14 Mar 2005 13:21:40 -0500 Subject: [C++-sig] Re: Problems with dynamic casts References: Message-ID: Aaron Bentley writes: > Hi, > I'm having a problem with dynamic casting on an object constructed using > Python. It seems as though the type of an owned object is being lost. > > I have a test as follows: > > assert (dynamic_cast(loc.getElement(elists[0])) > !=NULL); > > When I invoke it from the constructor of the owning object (the object > that owns elists), the test passes. But when I construct the owning > object and then invoke the test through Python, it fails. > > I'm using gcc 3.0.4 from Debian stable. > > This looks ugly to me. So far the only explanation I've been able to > come up with is memory corruption. I suggest you reduce your problem to the smallest possible example that illustrates it. The answer will probably become obvious to you, but if it doesn't, please post your example here. -- Dave Abrahams Boost Consulting www.boost-consulting.com From paniq at paniq.org Mon Mar 14 21:17:21 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Mon, 14 Mar 2005 21:17:21 +0100 Subject: [C++-sig] Sorry for my absence In-Reply-To: <20050314183713.GJ28551@ewok.lucasdigital.com> References: <20050312004809.GE28551@ewok.lucasdigital.com> <20050312021940.GG28551@ewok.lucasdigital.com> <1110604402.30511.3.camel@illuvatar> <20050314183713.GJ28551@ewok.lucasdigital.com> Message-ID: <4235F151.2020100@paniq.org> btw, no idea if this is really on topic, but i noticed a problem with pydoc/help() that made it raise an exception when generating documentation. i could reduce the problem to an enum attribute missing. with that attribute, the help procedure went quite fine. i think it might be good to natively include this attribute. see following example for module "mu": enum_("MouseButton") .value("Left",MouseButtonLeft) .value("Middle",MouseButtonMiddle) .value("Right",MouseButtonRight) .attr("__module__") = "mu" // without this attribute set, help() will raise an exception ; additionally i really miss the lack of parameter information that help() gives for exported functions. i dont think keywords should be mandatory to give people a clue on the parameter types. what about generating "hint" names for parameters from the type information if no keywords are submitted? e.g. "const char*" could be turned into "stringValue", "int" into "intValue", "Mu::Sandoz::View" into "muSandozViewValue", the second one into "muSandozViewValue2" and so on. i can imagine a complete partial template support coming on for boost.python users who want to specify their own type name translations for variables. something along the lines of template<> struct parameter_hint_from_type { const char* name() { return "muSandozView"; } }; what do you think? Nick Rasmussen wrote: >On Sat, 12 Mar 2005, Jonathan Brandmeyer wrote: > > > >>On Fri, 2005-03-11 at 18:19 -0800, Nick Rasmussen wrote: >> >> >>>Given that there wasn't any way to make the right way work, there >>>are three options that I came up with to make this work with existing >>>python versions: >>> >>>1: have end-users modify their installed inspect.py and/or pydoc.py files >>>2: replace inspect.isbuiltin dynamically on module load with a version >>> that understands boost function types. >>>3: fool pydoc into thinking that boost::python functions are instances >>> of the builtin function type. >>> >>> >>There is another option that I haven't had time to fully explore - make >>inspect.getmodule() work for a free Boost.Python.function. I think that >>if the code that makes Boost.Python.class objects' __module__ member >>work was applied to free function objects, a trivial change could be >>made to inspect.getmodule(). >> >> > >I thought about that as well, but here's what I came up with, given >the premise that we don't want to do #1 or #2 above: > >I checked the rest of the types that show up in inspect.getfile that >we could possibly use to fake out the existing code: FunctionType, >CodeType, FrameType, MethodType, aren't subclassable. ModuleType >is, but that doesn't seem like a good candidate to subclass, since >pydoc will ignore the function again. > >ClassType isn't subclassable, however inspect.isclass has an extra case that >doesn't show up in the other is* functions: hasattr(object,'__bases__') >If we add a __bases__ attribute to the function objects, inspect.isclass >will think its a class, and then if we stash a pointer to the module in >__module__ the lookup would work properly. Unfortunately, if inspect.isclass >reports the function as a class, pydoc tries to document it as such :/ > >-nick > >_______________________________________________ >C++-sig mailing list >C++-sig at python.org >http://mail.python.org/mailman/listinfo/c++-sig > > > > From paniq at paniq.org Mon Mar 14 21:21:46 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Mon, 14 Mar 2005 21:21:46 +0100 Subject: [C++-sig] another suggestion In-Reply-To: <20050314183713.GJ28551@ewok.lucasdigital.com> References: <20050312004809.GE28551@ewok.lucasdigital.com> <20050312021940.GG28551@ewok.lucasdigital.com> <1110604402.30511.3.camel@illuvatar> <20050314183713.GJ28551@ewok.lucasdigital.com> Message-ID: <4235F25A.9090908@paniq.org> also, there seems to be no possibility to get the original typeid(x).name() associated with a method, class or function from within python, although this would be nice in the cases where documentation is generated from reflection in python (yes i do that). From dan at theproverbial.com Mon Mar 14 22:32:31 2005 From: dan at theproverbial.com (Dan Haffey) Date: Mon, 14 Mar 2005 21:32:31 +0000 Subject: [C++-sig] cross-module RTTI issues Message-ID: <200503142132.32051.dan@theproverbial.com> Hello, I'm not sure if this is even the right place to post this question, but I'm having some trouble with inheritance across shared library boundaries. I've read the CrossExtensionModuleDependencies Wiki node, and I assume that my problem stems from std::type_info comparison problems, so my question is basically: how do I go about making sure my RTTI info is all coming from the same place? I'm specifically referring to this snippet from the Wiki: "The best way to achieve that is to link both extension modules to a common shared library using the global model, and put the RTTI information there." I'm not sure how exactly I get all the relevant RTTI information into that third library. Just incase I'm completely off-course with my diagnosis of the problem, here's an example of what I'm talking about (this breaks in Linux with gcc 3.3.4): --- A.hpp --- struct A { A() {} virtual int foo() = 0; }; struct Factory { Factory() {} virtual A* make() = 0; }; --- A.cpp --- #include "A.hpp" --- B.hpp --- #include "A.hpp" struct B : public A { B() {} virtual int foo(); }; struct DerivedFactory : public Factory { DerivedFactory() {} virtual A* make(); }; --- B.cpp --- #include "B.hpp" int B::foo() { return 42; } A* DerivedFactory::make() { return new B; } --- A.pyste --- A = Class('A', 'A.hpp') Factory = Class('Factory', 'A.hpp') set_policy(Factory.make, return_value_policy(reference_existing_object)) --- B.pyste --- B = Class('B', 'B.hpp') DerivedFactory = Class('DerivedFactory', 'B.hpp') set_policy(DerivedFactory.make, return_value_policy(reference_existing_object)) And in Python: >>> import A, B >>> x = B.DerivedFactory().make() >>> x.foo() Traceback (most recent call last): File "", line 1, in ? Boost.Python.ArgumentError: Python argument types in B.foo(B) did not match C++ signature: foo((anonymous namespace)::B_Wrapper {lvalue}) foo(B {lvalue}) >>> x = B.B() >>> x.foo() 42 >>> Is there a way around this behavior, or is there just no hope for this pattern of shared library usage? Any help would be greatly appreciated, -- Dan Haffey From nicodemus at esss.com.br Wed Mar 16 00:04:26 2005 From: nicodemus at esss.com.br (Nicodemus) Date: Tue, 15 Mar 2005 21:04:26 -0200 Subject: [C++-sig] Boost.Python: AllFromHeader In-Reply-To: References: Message-ID: <423769FA.9040703@esss.com.br> Hi Christopher, Christopher Mason wrote: > A quick question: AllFromHeader says: > > AllFromHeader is not working in all cases in the current version. > > (This is in boost_1_32_0.) > > Could someone please expound on this? Stay away completely? Use with > caveats? I've noticed that things seem to not be in the right order > (like Base->Derived dependencies). Is this part of the problem? That's exactly the problem. If I recall correctly, it doesn't generate base/derived dependencies when used with "--multiple" options, plus another bug that I can't remember right now. So, check your result: if it works, then you can use it ;) Regards, Bruno. From colin.goudie at gmail.com Wed Mar 16 07:01:52 2005 From: colin.goudie at gmail.com (Colin Goudie) Date: Wed, 16 Mar 2005 17:01:52 +1100 Subject: [C++-sig] A few questions about embedding python Message-ID: <4114432d0503152201dd148a5@mail.gmail.com> I'm using boost 1.32.0 with python 2.4 When I compile I get the python libraries created at boost\bin\boost\libs\python\build\ with the static library at boost\bin\boost\libs\python\build\libboost_python.lib\vc-7_1\debug\threading-multi\libboost_python-vc71-mt-gd-1_32.lib and the dynamic at boost\bin\boost\libs\python\build\boost_python.dll\vc-7_1\debug\threading-multi\boost_python-vc71-mt-gd-1_32.lib When I'm linking my program if I link against the static (Because I thought you had to do that for embedding) I get lots of unresolved external symbols that seem to come from boosts python library. If I link instead to the lib that belongs to the dll, and place the dll in with my exe it runs fine. ?? Do I need static linking on windows for embedding? The other question is with regards to exposing c++ classes to a python script loaded from a file. I have something like this in my c++ code BOOST_PYTHON_MODULE(truckstate) { class_("TruckState") .def("goLoading", &TruckState::goLoading) .def("gowaiting", &TruckState::goWaiting); } In my python script when I try to import truckstate I get an exception thrown saying it can't find the module truckstate Most of the examples I've seen importing c++ classes are when they are extending python not embedding. Do I need to use Python C/API to import my truckstate module or something?? Thanks From jesper.olsen at gmail.com Wed Mar 16 07:29:33 2005 From: jesper.olsen at gmail.com (Jesper Olsen) Date: Wed, 16 Mar 2005 08:29:33 +0200 Subject: [C++-sig] hello.pyd - where did it go? Message-ID: Hi, I just installed boost 1.32 on linux - I want to use Boost.Python. The installation seemed to go ok. After that I tried the hello world example http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.html % cd boost_1_32_0/libs/python/example/tutorial % bjam -sTOOLS=gcc -a This seems to work also - a hello.so is created and copied to boost_1_32_0/bin/boost/libs/python/example/tutorial/hello.so but where did hello.pyd go? The above hello.html page says it's supposed to be "somewhere in libs\python\example\tutorial\bin" But it's not there. I have not used bjam prior to boost so I'm a little confused - is it possible to see what the commandline eqivalents of what bjam is actually doing? Is boost usable without bjam? Cheers Jesper From nico_ml at mgdesign.org Wed Mar 16 11:22:40 2005 From: nico_ml at mgdesign.org (Nicolas Lelong) Date: Wed, 16 Mar 2005 11:22:40 +0100 Subject: [C++-sig] A few questions about embedding python References: <4114432d0503152201dd148a5@mail.gmail.com> Message-ID: <004a01c52a12$15c09e10$de00a8c0@nico> Hi, > ?? Do I need static linking on windows for embedding? It seems that you answered your own question, as it runs fine with the DLL, embedding is OK with dynamic linking. If you absolutely need static linking with BPL, perhaps you could send a sample of those linking errors you mentionned. > Most of the examples I've seen importing c++ classes are when they are > extending python not embedding. Do I need to use Python C/API to > import my truckstate module or something?? You effectively have to "declare" your module by calling : PyImport_AppendInittab("truckstate", inittruckstate); before the Py_Initialize() call, and I think that should do the trick ! HTH, Nicolas. From yangbing at kingsoft.com Wed Mar 16 12:53:35 2005 From: yangbing at kingsoft.com (??[?????]) Date: Wed, 16 Mar 2005 19:53:35 +0800 Subject: [C++-sig] Re: how to access live c++ object? References: <42354F3F.5070406@paniq.org> Message-ID: this is python code def run(): myFoo = HoHo_PI.getCT() a = myFoo.SetNum( 50 ) b=str(a) But b is none? why? thx "Leonard "paniq" Ritter" wrote in message news:42354F3F.5070406 at paniq.org... ... def("getCT",&getCT,return_value_policy()); ... ????[??????????] wrote: >This is my class >class CT >{ >public: > CT() {}; > ~CT() {}; > int GetNum( void ) { return num; } > void SetNum( int n ) { num = n; } > >private: > int num; >}; > >static CT ct; > >CT & getCT( void ) >{ > return ct; >} > >I want to access ct object from boost.python, thanks for your advice. > > > >_______________________________________________ >C++-sig mailing list >C++-sig at python.org >http://mail.python.org/mailman/listinfo/c++-sig > > > > From paniq at paniq.org Wed Mar 16 14:10:02 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Wed, 16 Mar 2005 14:10:02 +0100 Subject: [C++-sig] Re: how to access live c++ object? In-Reply-To: References: <42354F3F.5070406@paniq.org> Message-ID: <4238302A.5040205@paniq.org> if getCT had really failed, you would have get an exception when calling SetNum. try repr(a), and if the return type is None, SetNum is most probably of return type void. ??[?????] wrote: >this is python code >def run(): > myFoo = HoHo_PI.getCT() > a = myFoo.SetNum( 50 ) > b=str(a) > >But b is none? why? thx > > >"Leonard "paniq" Ritter" wrote in message >news:42354F3F.5070406 at paniq.org... >... > >def("getCT",&getCT,return_value_policy()); > >... > >????[??????????] wrote: > > > >>This is my class >>class CT >>{ >>public: >>CT() {}; >>~CT() {}; >>int GetNum( void ) { return num; } >>void SetNum( int n ) { num = n; } >> >>private: >>int num; >>}; >> >>static CT ct; >> >>CT & getCT( void ) >>{ >>return ct; >>} >> >>I want to access ct object from boost.python, thanks for your advice. >> >> >> >>_______________________________________________ >>C++-sig mailing list >>C++-sig at python.org >>http://mail.python.org/mailman/listinfo/c++-sig >> >> >> >> >> >> > > > >_______________________________________________ >C++-sig mailing list >C++-sig at python.org >http://mail.python.org/mailman/listinfo/c++-sig > > > > From abentley at panoramicfeedback.com Wed Mar 16 22:13:03 2005 From: abentley at panoramicfeedback.com (Aaron Bentley) Date: Wed, 16 Mar 2005 16:13:03 -0500 Subject: [C++-sig] Re: Problems with dynamic casts In-Reply-To: References: Message-ID: <4238A15F.5090507@panoramicfeedback.com> David Abrahams wrote: > Aaron Bentley writes: > > >>Hi, >>I'm having a problem with dynamic casting on an object constructed using >>Python. It seems as though the type of an owned object is being lost. > I suggest you reduce your problem to the smallest possible example > that illustrates it. The answer will probably become obvious to you, > but if it doesn't, please post your example here. Okay, here's some stripped down examples: ---foo.h--- class BaseClass { public: BaseClass() {} virtual ~BaseClass() {} }; ---foo.cpp--- ... SubClass *subclass_cast(BaseClass *el) { return dynamic_cast(el); } ---bar.h--- class SubClass: public BaseClass { public: SubClass(); }; SubClass *subclass_cast(BaseClass *el); void test_subclass(SubClass &el); ---bar.cpp--- ... SubClass::SubClass() { } void test_subclass(SubClass &el) { ; } --wrapper.cpp-- ... BaseClass *return_base(SubClass *el) { return el; } ... BOOST_PYTHON_MODULE(_element) { class_, boost::noncopyable>( "BaseClass", no_init) ; class_, bases, boost::noncopyable>("SubClass") ; def ("subclass_cast", subclass_cast, return_internal_reference<1>()); def ("test_subclass", test_subclass); def ("return_base", return_base, return_internal_reference<1>()); ... } --- test.py --- import _element def run_test(test_func, converter, caster, subclass): print "Testing %s" % subclass.__name__ subcl = subclass() try: test_func(subcl) print "subcl can be passed to %s directly" % test_func.__name__ except Exception, e: print print e print "subcl cannot be passed to %s directly:" % test_func.__name__ try: test_func(converter(subcl)) print "subcl can be passed to %s when returned as a base class" % \ test_func.__name__ except Exception, e: print print e print "subcl cannot be passed to %s when returned as a base class" % \ test_func.__name__ try: assert caster((subcl)) is not None print "subcl can be dynamically cast from subclass" except Exception, e: print if len(str(e)) > 0: print e print e.__class__ print "subcl cannot be dynamically cast from subclass" try: assert caster(converter(subcl)) is not None print "subcl can be dynamically cast from base class" except Exception, e: print if len(str(e)) > 0: print e print e.__class__ print "subcl cannot be dynamically cast from base class" run_test(_element.test_subclass, _element.return_base, _element.subclass_cast, _element.SubClass) Everything except wrapper.cpp is built as one shared library. When I run test.py, I get this: Testing SubClass subcl can be passed to test_subclass directly Python argument types in pflib._element.test_subclass(SubClass) did not match C++ signature: test_subclass(8SubClass {lvalue}) subcl cannot be passed to test_subclass when returned as a base class subcl can be dynamically cast from subclass subcl can be dynamically cast from base class If I change the constructor for SubClass to an inline constructor, I get this: Testing SubClass subcl can be passed to test_subclass directly subcl can be passed to test_subclass when returned as a base class exceptions.AssertionError subcl cannot be dynamically cast from subclass exceptions.AssertionError subcl cannot be dynamically cast from base class So it seems I can't do implicit dynamic casts (passing a base-class pointer to a function taking a subclass pointer) and explicit dynamic casts at the same time. Aaron -- Aaron Bentley Director of Technology Panometrics, Inc. From abentley at panoramicfeedback.com Wed Mar 16 22:13:03 2005 From: abentley at panoramicfeedback.com (Aaron Bentley) Date: Wed, 16 Mar 2005 16:13:03 -0500 Subject: [C++-sig] Re: Problems with dynamic casts In-Reply-To: References: Message-ID: <4238A15F.5090507@panoramicfeedback.com> David Abrahams wrote: > Aaron Bentley writes: > > >>Hi, >>I'm having a problem with dynamic casting on an object constructed using >>Python. It seems as though the type of an owned object is being lost. > I suggest you reduce your problem to the smallest possible example > that illustrates it. The answer will probably become obvious to you, > but if it doesn't, please post your example here. Okay, here's some stripped down examples: ---foo.h--- class BaseClass { public: BaseClass() {} virtual ~BaseClass() {} }; ---foo.cpp--- ... SubClass *subclass_cast(BaseClass *el) { return dynamic_cast(el); } ---bar.h--- class SubClass: public BaseClass { public: SubClass(); }; SubClass *subclass_cast(BaseClass *el); void test_subclass(SubClass &el); ---bar.cpp--- ... SubClass::SubClass() { } void test_subclass(SubClass &el) { ; } --wrapper.cpp-- ... BaseClass *return_base(SubClass *el) { return el; } ... BOOST_PYTHON_MODULE(_element) { class_, boost::noncopyable>( "BaseClass", no_init) ; class_, bases, boost::noncopyable>("SubClass") ; def ("subclass_cast", subclass_cast, return_internal_reference<1>()); def ("test_subclass", test_subclass); def ("return_base", return_base, return_internal_reference<1>()); ... } --- test.py --- import _element def run_test(test_func, converter, caster, subclass): print "Testing %s" % subclass.__name__ subcl = subclass() try: test_func(subcl) print "subcl can be passed to %s directly" % test_func.__name__ except Exception, e: print print e print "subcl cannot be passed to %s directly:" % test_func.__name__ try: test_func(converter(subcl)) print "subcl can be passed to %s when returned as a base class" % \ test_func.__name__ except Exception, e: print print e print "subcl cannot be passed to %s when returned as a base class" % \ test_func.__name__ try: assert caster((subcl)) is not None print "subcl can be dynamically cast from subclass" except Exception, e: print if len(str(e)) > 0: print e print e.__class__ print "subcl cannot be dynamically cast from subclass" try: assert caster(converter(subcl)) is not None print "subcl can be dynamically cast from base class" except Exception, e: print if len(str(e)) > 0: print e print e.__class__ print "subcl cannot be dynamically cast from base class" run_test(_element.test_subclass, _element.return_base, _element.subclass_cast, _element.SubClass) Everything except wrapper.cpp is built as one shared library. When I run test.py, I get this: Testing SubClass subcl can be passed to test_subclass directly Python argument types in pflib._element.test_subclass(SubClass) did not match C++ signature: test_subclass(8SubClass {lvalue}) subcl cannot be passed to test_subclass when returned as a base class subcl can be dynamically cast from subclass subcl can be dynamically cast from base class If I change the constructor for SubClass to an inline constructor, I get this: Testing SubClass subcl can be passed to test_subclass directly subcl can be passed to test_subclass when returned as a base class exceptions.AssertionError subcl cannot be dynamically cast from subclass exceptions.AssertionError subcl cannot be dynamically cast from base class So it seems I can't do implicit dynamic casts (passing a base-class pointer to a function taking a subclass pointer) and explicit dynamic casts at the same time. Aaron -- Aaron Bentley Director of Technology Panometrics, Inc. From yangbing at kingsoft.com Thu Mar 17 03:08:41 2005 From: yangbing at kingsoft.com (Ñî±ù[Ô´´úÂëÖ®¹â]) Date: Thu, 17 Mar 2005 10:08:41 +0800 Subject: [C++-sig] Re: Re: how to access live c++ object? References: <42354F3F.5070406@paniq.org> <4238302A.5040205@paniq.org> Message-ID: If the c++ object is pointer, How do I write def function? def("getCT",getCT,return_value_policy()); I think reference_existing_object may be changed, is right? "Leonard "paniq" Ritter" wrote in message news:4238302A.5040205 at paniq.org... if getCT had really failed, you would have get an exception when calling SetNum. try repr(a), and if the return type is None, SetNum is most probably of return type void. ??[?????] wrote: >this is python code >def run(): > myFoo = HoHo_PI.getCT() > a = myFoo.SetNum( 50 ) > b=str(a) > >But b is none? why? thx > > >"Leonard "paniq" Ritter" wrote in message >news:42354F3F.5070406 at paniq.org... >... > >def("getCT",&getCT,return_value_policy()); > >... > >????[??????????] wrote: > > > >>This is my class >>class CT >>{ >>public: >>CT() {}; >>~CT() {}; >>int GetNum( void ) { return num; } >>void SetNum( int n ) { num = n; } >> >>private: >>int num; >>}; >> >>static CT ct; >> >>CT & getCT( void ) >>{ >>return ct; >>} >> >>I want to access ct object from boost.python, thanks for your advice. >> >> >> >>_______________________________________________ >>C++-sig mailing list >>C++-sig at python.org >>http://mail.python.org/mailman/listinfo/c++-sig >> >> >> >> >> >> > > > >_______________________________________________ >C++-sig mailing list >C++-sig at python.org >http://mail.python.org/mailman/listinfo/c++-sig > > > > From yangbing at kingsoft.com Thu Mar 17 03:58:47 2005 From: yangbing at kingsoft.com (??[?????]) Date: Thu, 17 Mar 2005 10:58:47 +0800 Subject: [C++-sig] Re: Re: a working example of wrapping an instantiatedc++ object References: <20041207181527.49901.qmail@web40822.mail.yahoo.com> Message-ID: waiting for your post. : ) "Yao Heling" wrote in message news:20041207181527.49901.qmail at web40822.mail.yahoo.com... > Ok, I'll try to write a small tutorial for this. I'll > post it here when > it's ready. > > Thanks for your help, > > Joseph > > > > > __________________________________ > Do you Yahoo!? > The all-new My Yahoo! - What will yours do? > http://my.yahoo.com From Michal.Kandulski at poczta.onet.pl Wed Mar 16 16:44:45 2005 From: Michal.Kandulski at poczta.onet.pl (Michal Kandulski) Date: Wed, 16 Mar 2005 16:44:45 +0100 Subject: [C++-sig] Boost.Python: An attempt compile with Borland Message-ID: Hi, Is anyone interested in making Boost.Python compile with Borland? Has anyone tried to do it? Is there any reason for which it is impossible? Im rather new to Boost.Python although quite experienced in C++. I've read the tutorial and I like the project very much. I've also tried some of the examples with mingw. Unfortunately I'm using the Borland compiler and this is something I can't change :-(. I know the library won't compile with Borland because of it's poor template implementation (and lots of other bugs). But... I tried to make it compile and I'm almost (99%) successful. All the cpp's get compiled. But... it simply does'n work because of some compiler features (differences), either in compiletime or in runtime. HELP! Michal From paniq at paniq.org Thu Mar 17 11:30:48 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Thu, 17 Mar 2005 11:30:48 +0100 Subject: [C++-sig] Re: Re: how to access live c++ object? In-Reply-To: References: <42354F3F.5070406@paniq.org> <4238302A.5040205@paniq.org> Message-ID: <42395C58.1050202@paniq.org> i dont understand you at all. have you read http://www.boost.org/libs/python/doc/tutorial/doc/html/index.html and especially http://www.boost.org/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies ????[??????????] wrote: >If the c++ object is pointer, How do I write def function? >def("getCT",getCT,return_value_policy()); > >I think reference_existing_object may be changed, is right? > >"Leonard "paniq" Ritter" wrote in message >news:4238302A.5040205 at paniq.org... >if getCT had really failed, you would have get an exception when calling >SetNum. try repr(a), and if the return type is None, SetNum is most >probably of return type void. > >??[?????] wrote: > > > >>this is python code >>def run(): >>myFoo = HoHo_PI.getCT() >>a = myFoo.SetNum( 50 ) >>b=str(a) >> >>But b is none? why? thx >> >> >>"Leonard "paniq" Ritter" wrote in message >>news:42354F3F.5070406 at paniq.org... >>... >> >>def("getCT",&getCT,return_value_policy()); >> >>... >> >>????[??????????] wrote: >> >> >> >> >> >>>This is my class >>>class CT >>>{ >>>public: >>>CT() {}; >>>~CT() {}; >>>int GetNum( void ) { return num; } >>>void SetNum( int n ) { num = n; } >>> >>>private: >>>int num; >>>}; >>> >>>static CT ct; >>> >>>CT & getCT( void ) >>>{ >>>return ct; >>>} >>> >>>I want to access ct object from boost.python, thanks for your advice. >>> >>> >>> >>>_______________________________________________ >>>C++-sig mailing list >>>C++-sig at python.org >>>http://mail.python.org/mailman/listinfo/c++-sig >>> >>> >>> >>> >>> >>> >>> >>> >> >>_______________________________________________ >>C++-sig mailing list >>C++-sig at python.org >>http://mail.python.org/mailman/listinfo/c++-sig >> >> >> >> >> >> > > > > >_______________________________________________ >C++-sig mailing list >C++-sig at python.org >http://mail.python.org/mailman/listinfo/c++-sig > > > > From dave at boost-consulting.com Thu Mar 17 15:48:23 2005 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 17 Mar 2005 09:48:23 -0500 Subject: [C++-sig] Re: exporting __stdcall methods In-Reply-To: <024f01c52a4b$5caa5df0$0dc66b51@fuji> (John Maddock's message of "Wed, 16 Mar 2005 17:09:35 -0000") References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <005101c52759$ee9cc030$37ce4e51@MIKESPC01> <42337D6E.2010505@paniq.org> <024f01c52a4b$5caa5df0$0dc66b51@fuji> Message-ID: "John Maddock" writes: >> Files like boost/type_traits/detail/is_mem_fun_pointer_tester.hpp >> which are outside the Boost.Python library would need to be enhanced >> to deal with __stdcall, etc. > > Should now be fixed in cvs: provided the changes don't break anything else > of course! Fantastic! Thanks, John! -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Mar 17 16:15:28 2005 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 17 Mar 2005 10:15:28 -0500 Subject: [C++-sig] Re: hello.pyd - where did it go? References: Message-ID: Jesper Olsen writes: > Hi, > > I just installed boost 1.32 on linux - I want to use Boost.Python. > > The installation seemed to go ok. > > After that I tried the hello world example > > http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.html > > % cd boost_1_32_0/libs/python/example/tutorial > % bjam -sTOOLS=gcc -a > > This seems to work also - a hello.so is created and copied to > > boost_1_32_0/bin/boost/libs/python/example/tutorial/hello.so > > but where did hello.pyd go? The above hello.html page says it's > supposed to be "somewhere in libs\python\example\tutorial\bin" > > But it's not there. > > I have not used bjam prior to boost so I'm a little confused - is it > possible to see > what the commandline eqivalents of what bjam is actually doing? Add "-d+2" to your bjam command line, just after "bjam" If you've already built something, use "-a" to cause bjam to treat everything as being out-of-date and "-n" to cause bjam not to build anything, but display the commands that would be executed. -- Dave Abrahams Boost Consulting www.boost-consulting.com From djowel at gmail.com Thu Mar 17 16:49:32 2005 From: djowel at gmail.com (Joel de Guzman) Date: Thu, 17 Mar 2005 23:49:32 +0800 Subject: [C++-sig] Re: hello.pyd - where did it go? In-Reply-To: References: Message-ID: <4239A70C.6090406@boost-consulting.com> David Abrahams wrote: > Jesper Olsen writes: > > >>Hi, >> >>I just installed boost 1.32 on linux - I want to use Boost.Python. >> >>The installation seemed to go ok. >> >>After that I tried the hello world example >> >>http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.html >> >>% cd boost_1_32_0/libs/python/example/tutorial >>% bjam -sTOOLS=gcc -a >> >>This seems to work also - a hello.so is created and copied to >> >>boost_1_32_0/bin/boost/libs/python/example/tutorial/hello.so >> >>but where did hello.pyd go? The above hello.html page says it's >>supposed to be "somewhere in libs\python\example\tutorial\bin" >> >>But it's not there. >> >>I have not used bjam prior to boost so I'm a little confused - is it >>possible to see >>what the commandline eqivalents of what bjam is actually doing? > > > Add "-d+2" to your bjam command line, just after "bjam" > > If you've already built something, use > "-a" to cause bjam to treat everything as being out-of-date > and "-n" to cause bjam not to build anything, but display the > commands that would be executed. Time to update the tutorial? Is it not a good idea to put bjam generated directory paths there since these are subject to change? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From paniq at paniq.org Thu Mar 17 17:19:27 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Thu, 17 Mar 2005 17:19:27 +0100 Subject: [C++-sig] Re: exporting __stdcall methods In-Reply-To: References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> <422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org> <005101c52759$ee9cc030$37ce4e51@MIKESPC01> <42337D6E.2010505@paniq.org> <024f01c52a4b$5caa5df0$0dc66b51@fuji> Message-ID: <4239AE0F.5020108@paniq.org> David Abrahams wrote: >"John Maddock" writes: > > > >>>Files like boost/type_traits/detail/is_mem_fun_pointer_tester.hpp >>>which are outside the Boost.Python library would need to be enhanced >>>to deal with __stdcall, etc. >>> >>> >>Should now be fixed in cvs: provided the changes don't break anything else >>of course! >> >> > >Fantastic! Thanks, John! > > > weee! From jesper.olsen at gmail.com Thu Mar 17 17:54:19 2005 From: jesper.olsen at gmail.com (Jesper Olsen) Date: Thu, 17 Mar 2005 18:54:19 +0200 Subject: [C++-sig] Re: hello.pyd - where did it go? In-Reply-To: <4239A70C.6090406@boost-consulting.com> References: <4239A70C.6090406@boost-consulting.com> Message-ID: On Thu, 17 Mar 2005 23:49:32 +0800, Joel de Guzman wrote: > David Abrahams wrote: > > Jesper Olsen writes: > >>I have not used bjam prior to boost so I'm a little confused - is it > >>possible to see > >>what the commandline eqivalents of what bjam is actually doing? > > > > > > Add "-d+2" to your bjam command line, just after "bjam" > > > > If you've already built something, use > > "-a" to cause bjam to treat everything as being out-of-date > > and "-n" to cause bjam not to build anything, but display the > > commands that would be executed. > > Time to update the tutorial? Is it not a good idea to put > bjam generated directory paths there since these are subject > to change? Thanks. I was able to run the tutorial - what was necessary after running bjam in the example/tutorial directory, was to add .../../../../bin/boost/libs/python/example/tutorial/hello.so/gcc/debug/shared-linkable-true/ to sys.path (python) and setting the shell variable LD_LIBRARY_PATH LD_LIBRARY_PATH=/usr/local/lib/python2.4/config:../../../../bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true:$LD_LIBRARY_PATH Looking at the bjam -d 2 output it seems it tries to set LD_LIBRARY_PATH to this value - but it is not defined when it finishes... Anyway - I'm glad it's working now. I think the python bridge is very cool - much easier than writing the usual c interface files. However - installation and distribution of code is less streamlined than using python distutils - but I guess it was not the intention to replace that anyway. Cheers Jesper From yangbing at kingsoft.com Fri Mar 18 06:09:55 2005 From: yangbing at kingsoft.com (??[?????]) Date: Fri, 18 Mar 2005 13:09:55 +0800 Subject: [C++-sig] Re: Re: Re: how to access live c++ object? References: <42354F3F.5070406@paniq.org> <4238302A.5040205@paniq.org> <42395C58.1050202@paniq.org> Message-ID: The problem has been solved , thanks.... "Leonard "paniq" Ritter" wrote in message news:42395C58.1050202 at paniq.org... i dont understand you at all. have you read http://www.boost.org/libs/python/doc/tutorial/doc/html/index.html and especially http://www.boost.org/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies ????[??????????] wrote: >If the c++ object is pointer, How do I write def function? >def("getCT",getCT,return_value_policy()); > >I think reference_existing_object may be changed, is right? > >"Leonard "paniq" Ritter" wrote in message >news:4238302A.5040205 at paniq.org... >if getCT had really failed, you would have get an exception when calling >SetNum. try repr(a), and if the return type is None, SetNum is most >probably of return type void. > >??[?????] wrote: > > > >>this is python code >>def run(): >>myFoo = HoHo_PI.getCT() >>a = myFoo.SetNum( 50 ) >>b=str(a) >> >>But b is none? why? thx >> >> >>"Leonard "paniq" Ritter" wrote in message >>news:42354F3F.5070406 at paniq.org... >>... >> >>def("getCT",&getCT,return_value_policy()); >> >>... >> >>????[??????????] wrote: >> >> >> >> >> >>>This is my class >>>class CT >>>{ >>>public: >>>CT() {}; >>>~CT() {}; >>>int GetNum( void ) { return num; } >>>void SetNum( int n ) { num = n; } >>> >>>private: >>>int num; >>>}; >>> >>>static CT ct; >>> >>>CT & getCT( void ) >>>{ >>>return ct; >>>} >>> >>>I want to access ct object from boost.python, thanks for your advice. >>> >>> >>> >>>_______________________________________________ >>>C++-sig mailing list >>>C++-sig at python.org >>>http://mail.python.org/mailman/listinfo/c++-sig >>> >>> >>> >>> >>> >>> >>> >>> >> >>_______________________________________________ >>C++-sig mailing list >>C++-sig at python.org >>http://mail.python.org/mailman/listinfo/c++-sig >> >> >> >> >> >> > > > > >_______________________________________________ >C++-sig mailing list >C++-sig at python.org >http://mail.python.org/mailman/listinfo/c++-sig > > > > From abentley at panoramicfeedback.com Fri Mar 18 17:03:28 2005 From: abentley at panoramicfeedback.com (Aaron Bentley) Date: Fri, 18 Mar 2005 11:03:28 -0500 Subject: [C++-sig] Re: Problems with dynamic casts In-Reply-To: <4238A15F.5090507@panoramicfeedback.com> References: <4238A15F.5090507@panoramicfeedback.com> Message-ID: <423AFBD0.8000504@panoramicfeedback.com> Does anyone have any suggestions for dealing with these issues? Aaron Aaron Bentley wrote: > David Abrahams wrote: > >> Aaron Bentley writes: >> >> >>> Hi, >>> I'm having a problem with dynamic casting on an object constructed >>> using Python. It seems as though the type of an owned object is >>> being lost. > > >> I suggest you reduce your problem to the smallest possible example >> that illustrates it. The answer will probably become obvious to you, >> but if it doesn't, please post your example here. > > > Okay, here's some stripped down examples: > > ---foo.h--- > class BaseClass > { > public: > BaseClass() > {} > virtual ~BaseClass() > {} > }; > > ---foo.cpp--- > ... > SubClass *subclass_cast(BaseClass *el) > { > return dynamic_cast(el); > } > ---bar.h--- > class SubClass: public BaseClass > { > public: > SubClass(); > }; > SubClass *subclass_cast(BaseClass *el); > > void test_subclass(SubClass &el); > ---bar.cpp--- > ... > SubClass::SubClass() > { > } > void test_subclass(SubClass &el) > { > ; > } > --wrapper.cpp-- > ... > BaseClass *return_base(SubClass *el) > { > return el; > } > ... > BOOST_PYTHON_MODULE(_element) > { > class_, boost::noncopyable>( > "BaseClass", no_init) > ; > class_, bases, > boost::noncopyable>("SubClass") > ; > def ("subclass_cast", subclass_cast, return_internal_reference<1>()); > def ("test_subclass", test_subclass); > def ("return_base", return_base, return_internal_reference<1>()); > > ... > } > --- test.py --- > import _element > def run_test(test_func, converter, caster, subclass): > print "Testing %s" % subclass.__name__ > subcl = subclass() > try: > test_func(subcl) > print "subcl can be passed to %s directly" % test_func.__name__ > except Exception, e: > print > print e > print "subcl cannot be passed to %s directly:" % test_func.__name__ > try: > test_func(converter(subcl)) > print "subcl can be passed to %s when returned as a base class" % \ > test_func.__name__ > except Exception, e: > print > print e > print "subcl cannot be passed to %s when returned as a base > class" % \ > test_func.__name__ > try: > assert caster((subcl)) is not None > print "subcl can be dynamically cast from subclass" > except Exception, e: > print > if len(str(e)) > 0: > print e > print e.__class__ > print "subcl cannot be dynamically cast from subclass" > try: > assert caster(converter(subcl)) is not None > print "subcl can be dynamically cast from base class" > except Exception, e: > print > if len(str(e)) > 0: > print e > print e.__class__ > print "subcl cannot be dynamically cast from base class" > run_test(_element.test_subclass, _element.return_base, > _element.subclass_cast, _element.SubClass) > > > Everything except wrapper.cpp is built as one shared library. > > When I run test.py, I get this: > Testing SubClass > subcl can be passed to test_subclass directly > > Python argument types in > pflib._element.test_subclass(SubClass) > did not match C++ signature: > test_subclass(8SubClass {lvalue}) > subcl cannot be passed to test_subclass when returned as a base class > subcl can be dynamically cast from subclass > subcl can be dynamically cast from base class > > If I change the constructor for SubClass to an inline constructor, I get > this: > Testing SubClass > subcl can be passed to test_subclass directly > subcl can be passed to test_subclass when returned as a base class > > exceptions.AssertionError > subcl cannot be dynamically cast from subclass > > exceptions.AssertionError > subcl cannot be dynamically cast from base class > > So it seems I can't do implicit dynamic casts (passing a base-class > pointer to a function taking a subclass pointer) and explicit dynamic > casts at the same time. > > Aaron > -- Aaron Bentley Director of Technology Panometrics, Inc. From abentley at panoramicfeedback.com Fri Mar 18 17:03:28 2005 From: abentley at panoramicfeedback.com (Aaron Bentley) Date: Fri, 18 Mar 2005 11:03:28 -0500 Subject: [C++-sig] Re: Problems with dynamic casts In-Reply-To: <4238A15F.5090507@panoramicfeedback.com> References: <4238A15F.5090507@panoramicfeedback.com> Message-ID: <423AFBD0.8000504@panoramicfeedback.com> Does anyone have any suggestions for dealing with these issues? Aaron Aaron Bentley wrote: > David Abrahams wrote: > >> Aaron Bentley writes: >> >> >>> Hi, >>> I'm having a problem with dynamic casting on an object constructed >>> using Python. It seems as though the type of an owned object is >>> being lost. > > >> I suggest you reduce your problem to the smallest possible example >> that illustrates it. The answer will probably become obvious to you, >> but if it doesn't, please post your example here. > > > Okay, here's some stripped down examples: > > ---foo.h--- > class BaseClass > { > public: > BaseClass() > {} > virtual ~BaseClass() > {} > }; > > ---foo.cpp--- > ... > SubClass *subclass_cast(BaseClass *el) > { > return dynamic_cast(el); > } > ---bar.h--- > class SubClass: public BaseClass > { > public: > SubClass(); > }; > SubClass *subclass_cast(BaseClass *el); > > void test_subclass(SubClass &el); > ---bar.cpp--- > ... > SubClass::SubClass() > { > } > void test_subclass(SubClass &el) > { > ; > } > --wrapper.cpp-- > ... > BaseClass *return_base(SubClass *el) > { > return el; > } > ... > BOOST_PYTHON_MODULE(_element) > { > class_, boost::noncopyable>( > "BaseClass", no_init) > ; > class_, bases, > boost::noncopyable>("SubClass") > ; > def ("subclass_cast", subclass_cast, return_internal_reference<1>()); > def ("test_subclass", test_subclass); > def ("return_base", return_base, return_internal_reference<1>()); > > ... > } > --- test.py --- > import _element > def run_test(test_func, converter, caster, subclass): > print "Testing %s" % subclass.__name__ > subcl = subclass() > try: > test_func(subcl) > print "subcl can be passed to %s directly" % test_func.__name__ > except Exception, e: > print > print e > print "subcl cannot be passed to %s directly:" % test_func.__name__ > try: > test_func(converter(subcl)) > print "subcl can be passed to %s when returned as a base class" % \ > test_func.__name__ > except Exception, e: > print > print e > print "subcl cannot be passed to %s when returned as a base > class" % \ > test_func.__name__ > try: > assert caster((subcl)) is not None > print "subcl can be dynamically cast from subclass" > except Exception, e: > print > if len(str(e)) > 0: > print e > print e.__class__ > print "subcl cannot be dynamically cast from subclass" > try: > assert caster(converter(subcl)) is not None > print "subcl can be dynamically cast from base class" > except Exception, e: > print > if len(str(e)) > 0: > print e > print e.__class__ > print "subcl cannot be dynamically cast from base class" > run_test(_element.test_subclass, _element.return_base, > _element.subclass_cast, _element.SubClass) > > > Everything except wrapper.cpp is built as one shared library. > > When I run test.py, I get this: > Testing SubClass > subcl can be passed to test_subclass directly > > Python argument types in > pflib._element.test_subclass(SubClass) > did not match C++ signature: > test_subclass(8SubClass {lvalue}) > subcl cannot be passed to test_subclass when returned as a base class > subcl can be dynamically cast from subclass > subcl can be dynamically cast from base class > > If I change the constructor for SubClass to an inline constructor, I get > this: > Testing SubClass > subcl can be passed to test_subclass directly > subcl can be passed to test_subclass when returned as a base class > > exceptions.AssertionError > subcl cannot be dynamically cast from subclass > > exceptions.AssertionError > subcl cannot be dynamically cast from base class > > So it seems I can't do implicit dynamic casts (passing a base-class > pointer to a function taking a subclass pointer) and explicit dynamic > casts at the same time. > > Aaron > -- Aaron Bentley Director of Technology Panometrics, Inc. From dave at boost-consulting.com Tue Mar 15 19:10:40 2005 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 15 Mar 2005 13:10:40 -0500 Subject: [C++-sig] Re: cross-module RTTI issues References: <200503142132.32051.dan@theproverbial.com> Message-ID: Dan Haffey writes: > I'm not sure if this is even the right place to post this question, but I'm > having some trouble with inheritance across shared library boundaries. I've > read the CrossExtensionModuleDependencies Wiki node, and I assume that my > problem stems from std::type_info comparison problems, so my question is > basically: how do I go about making sure my RTTI info is all coming from the > same place? > > I'm specifically referring to this snippet from the Wiki: > "The best way to achieve that is to link both extension modules to a common > shared library using the global model, and put the RTTI information there." > > I'm not sure how exactly I get all the relevant RTTI information into that > third library. Put the base classes there. What it takes to generate the RTTI information will vary from compiler-to-compiler. Usually implementing one virtual function there is enough. Sometimes even a non-virtual function is sufficient. If your base classes have only pure virtual functions, you can still provide an implementation for one. If all else fails, you might try putting a dummy function in that library that uses dynamic_cast(some_base_ptr). Good luck! -- Dave Abrahams Boost Consulting www.boost-consulting.com From dhaffey at gmail.com Sat Mar 19 01:49:04 2005 From: dhaffey at gmail.com (Dan Haffey) Date: Sat, 19 Mar 2005 00:49:04 +0000 Subject: [C++-sig] Re: Problems with dynamic casts In-Reply-To: <423AFBD0.8000504@panoramicfeedback.com> References: <4238A15F.5090507@panoramicfeedback.com> <423AFBD0.8000504@panoramicfeedback.com> Message-ID: <5ab8740205031816492a83189a@mail.gmail.com> On Fri, 18 Mar 2005 11:03:28 -0500, Aaron Bentley wrote: > Does anyone have any suggestions for dealing with these issues? > > Aaron I'm having what looks to be the same problem. I *think* that the meat of the issue is addressed here: http://www.python.org/moin/boost.python/CrossExtensionModuleDependencies So then it becomes a matter of controlling where the compiler (I assume you're also using gcc 3?) emits vtables. I've tried (more or less blindly) several different methods to get that information into a common third shared library that gets loaded first, but nothing I've tried seems to solve the problem. While searching for information on this, I stumbled across some posts by Dave Abrahams on the gcc mailing list regarding this issue (or so it seems), but the technical details were pretty much over my head. I got the impression that the current method used for resolving weak symbols is not exactly ideal for our purposes, but I'm still not sure about the status of a decent workaround. -- Dan Haffey From dhaffey at gmail.com Sat Mar 19 15:23:16 2005 From: dhaffey at gmail.com (Dan Haffey) Date: Sat, 19 Mar 2005 14:23:16 +0000 Subject: [C++-sig] Re: Problems with dynamic casts In-Reply-To: <5ab8740205031816492a83189a@mail.gmail.com> References: <4238A15F.5090507@panoramicfeedback.com> <423AFBD0.8000504@panoramicfeedback.com> <5ab8740205031816492a83189a@mail.gmail.com> Message-ID: <5ab8740205031906233a7618b@mail.gmail.com> > I'm having what looks to be the same problem. Please disregard that message, it turns out that in my case, PEBKAC (been too long since I'd RTFM for Pyste wrt inheritance). For what it's worth, I compiled your example and it ran fine for me (with gcc 3.3.4). I notice that the class name in part of your exception text is preceded by an 8, which looks like part of the mangled name. Whenever I get the "did not match C++ signature" error, the class name matches up. Maybe your compiler is playing funny games? -- Dan Haffey From dholth at fastmail.fm Sun Mar 20 01:37:56 2005 From: dholth at fastmail.fm (Daniel Holth) Date: Sat, 19 Mar 2005 19:37:56 -0500 Subject: [C++-sig] linker problems with boost.build and C++ embedding Message-ID: <423CC5E4.1050600@fastmail.fm> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In gentoo Linux I have edited my code, but have not subtracted from the linker options at all, now a module imported into my embedded Python environment cannot find symbols from the Python library. ImportError: /usr/lib/python2.3/site-packages/_mysql.so: undefined symbol: PyType_GenericNew I have no idea why this is happening, I just know I've had the same problem with dynamic shared objects before. Can anyone here tell me what the issue might be? It was importing just fine, and then I added another static library and edited some code, now my embedded Python code can't import. Thanks, Daniel Holth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCPMXkVh4W2pVfoMsRAtWQAJ9qKQmMi77RREZKuzrAwsg0juqIDQCg8OI+ yfl6aFVPOidpxQALAD8YGrk= =oLJq -----END PGP SIGNATURE----- From dhaffey at gmail.com Sun Mar 20 11:16:49 2005 From: dhaffey at gmail.com (Dan Haffey) Date: Sun, 20 Mar 2005 10:16:49 +0000 Subject: [C++-sig] Pyste bug? Using Wrapper with member functions and --pyste-ns Message-ID: <5ab8740205032002161499b77d@mail.gmail.com> Hello, I just noticed that when using the Pyste Wrapper call to create a member function wrapper, it places the wrapper definition code outside of the specified (--pyste-ns=) namespace, but the generated module code looks for it in the namespace. This doesn't seem to happen with normal functions, just members. -- Dan Haffey From clay at idleengineer.net Sun Mar 20 20:16:24 2005 From: clay at idleengineer.net (Clay Culver) Date: Sun, 20 Mar 2005 14:16:24 -0500 Subject: [C++-sig] Boost.Python with MSVC < v7.1 Message-ID: <423DCC08.3020504@idleengineer.net> This list seems to have fallen out of date: http://boost.org/libs/python/doc/v2/platforms.html I am working on a GUI widget which uses embedded python. Under windows, the GUI system supports MSVC 6.0, 7.0, and 7.1. If I use Boost.Python will this restrict my widget to being MSVC 7.1 only? I have heard that the current Boost.Python only really works under 7.1, but I don't see anything about it in the documentation. Thanks. Clay From dave at boost-consulting.com Sun Mar 20 21:42:01 2005 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 20 Mar 2005 15:42:01 -0500 Subject: [C++-sig] Re: hello.pyd - where did it go? References: <4239A70C.6090406@boost-consulting.com> Message-ID: Jesper Olsen writes: > On Thu, 17 Mar 2005 23:49:32 +0800, Joel de Guzman wrote: >> David Abrahams wrote: >> > Jesper Olsen writes: > >> >>I have not used bjam prior to boost so I'm a little confused - is it >> >>possible to see >> >>what the commandline eqivalents of what bjam is actually doing? >> > >> > >> > Add "-d+2" to your bjam command line, just after "bjam" >> > >> > If you've already built something, use >> > "-a" to cause bjam to treat everything as being out-of-date >> > and "-n" to cause bjam not to build anything, but display the >> > commands that would be executed. >> >> Time to update the tutorial? Is it not a good idea to put >> bjam generated directory paths there since these are subject >> to change? > > Thanks. > > I was able to run the tutorial - what was necessary after running bjam > in the example/tutorial directory, was to add > .../../../../bin/boost/libs/python/example/tutorial/hello.so/gcc/debug/shared-linkable-true/ > to sys.path (python) and setting the shell variable LD_LIBRARY_PATH > LD_LIBRARY_PATH=/usr/local/lib/python2.4/config:../../../../bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true:$LD_LIBRARY_PATH That should not be neccessary. There are testing rules to run python tests from within the bjam invocation; they set up the paths as neccessary and then run python. > Looking at the bjam -d 2 output it seems it tries to set > LD_LIBRARY_PATH to this value Yes. > - but it is not defined when it finishes... I don't know what you mean. If you were expecting that LD_LIBRARY_PATH setting to remain after the bjam invocation is complete, well, Boost.Build intentionally does not alter anything in the invocation environment. > Anyway - I'm glad it's working now. > I think the python bridge is very cool - much easier than writing the > usual c interface files. > However - installation and distribution of code is less streamlined > than using python distutils - but I guess it was not the intention to > replace that anyway. Well, it is our intention to fully replace distutils for the purposes of C++, very soon. And distutils was very bad at dealing with C++ last time I looked. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dholth at fastmail.fm Sun Mar 20 23:20:59 2005 From: dholth at fastmail.fm (Daniel Holth) Date: Sun, 20 Mar 2005 17:20:59 -0500 Subject: [C++-sig] Embedded Python plus module loading Message-ID: <423DF74B.7060101@fastmail.fm> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Okay, I've put a minimal example together. http://dingoskidneys.com/~dholth/minimal-embedding-failure.zip It is the embedding example from boost, with an "import sha" statement added inside it. sha depends on some dynamically loaded code. When I try to run it, it says: ImportError: /usr/lib/python2.3/lib-dynload/sha.so: undefined symbol: Py_FindMethod My Jamfile: project-root ; # Include definitions needed for Python modules SEARCH on python.jam = $(BOOST_BUILD_PATH) ; import python ; # The boost-jam embedding example exe embedding ~ : # sources ~ embedding.cpp ~ : # requirements ~ multi ~ boost_python ~ $(PYTHON_PROPERTIES) ~ $(PYTHON_LIB_PATH) ~ $(PYTHON_EMBEDDED_LIBRARY) ~ ; I'm not sure where I'm going wrong and I'd appreciate some advice. Embedded Python is more useful when you can load dso's. Thanks, Daniel Holth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCPfdLVh4W2pVfoMsRAtsdAKC/d+5VZRWW5O1N1TgEKnVKnlZsFgCdEzTI D6y1iipDrSYmFAl36ykgtoE= =NcnH -----END PGP SIGNATURE----- From dave at boost-consulting.com Mon Mar 21 00:24:09 2005 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 20 Mar 2005 18:24:09 -0500 Subject: [C++-sig] Re: Boost.Python with MSVC < v7.1 References: <423DCC08.3020504@idleengineer.net> Message-ID: Clay Culver writes: > This list seems to have fallen out of date: > http://boost.org/libs/python/doc/v2/platforms.html Yep. > I am working on a GUI widget which uses embedded python. Under windows, > the GUI system supports MSVC 6.0, 7.0, and 7.1. If I use Boost.Python > will this restrict my widget to being MSVC 7.1 only? No, it works fine with vc6 and vc7. -- Dave Abrahams Boost Consulting www.boost-consulting.com From clay at idleengineer.net Mon Mar 21 00:41:54 2005 From: clay at idleengineer.net (Clay Culver) Date: Sun, 20 Mar 2005 18:41:54 -0500 Subject: [C++-sig] Re: Boost.Python with MSVC < v7.1 In-Reply-To: References: <423DCC08.3020504@idleengineer.net> Message-ID: <423E0A42.3050104@idleengineer.net> David Abrahams wrote: >No, it works fine with vc6 and vc7. > Ah excellent, thanks. From dholth at fastmail.fm Mon Mar 21 05:21:40 2005 From: dholth at fastmail.fm (Daniel Holth) Date: Sun, 20 Mar 2005 23:21:40 -0500 Subject: [C++-sig] Embedded Python plus module loading In-Reply-To: <423DF74B.7060101@fastmail.fm> References: <423DF74B.7060101@fastmail.fm> Message-ID: <1111378901.25605.11.camel@bluefish> On Sun, 2005-03-20 at 17:20 -0500, Daniel Holth wrote: > My Jamfile: > > project-root ; > > # Include definitions needed for Python modules > SEARCH on python.jam = $(BOOST_BUILD_PATH) ; > import python ; > > # The boost-jam embedding example > exe embedding > ~ : # sources > ~ embedding.cpp > ~ : # requirements > ~ multi > ~ boost_python > ~ $(PYTHON_PROPERTIES) > ~ $(PYTHON_LIB_PATH) > ~ $(PYTHON_EMBEDDED_LIBRARY) > ~ ; > > > I'm not sure where I'm going wrong and I'd appreciate some advice. > Embedded Python is more useful when you can load dso's. I've figured it out, more or less. When I link to libpython2.3.so rather than the static Python library it works fine. Doesn't answer the question of why my other program suddenly stopped working re: importing, but it does fix it. # The boost-jam embedding example exe embedding : # sources embedding.cpp : # requirements multi # my system's Python library is threaded python2.3 boost_python ; which imports sha without incident. Except it doesn't set the include path, so the same jamfile won't both compile my code and link it. So now I just have to work out the arguments to get it to link with the shared library and set the include path properly... perplexing. Thanks for any advice, Daniel Holth -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dave at boost-consulting.com Mon Mar 21 09:52:09 2005 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 21 Mar 2005 03:52:09 -0500 Subject: [C++-sig] Re: Embedded Python plus module loading References: <423DF74B.7060101@fastmail.fm> <1111378901.25605.11.camel@bluefish> Message-ID: Daniel Holth writes: > I've figured it out, more or less. When I link to libpython2.3.so rather > than the static Python library it works fine. Doesn't answer the > question of why my other program suddenly stopped working re: importing, > but it does fix it. > > # The boost-jam embedding example > exe embedding > : # sources > embedding.cpp > : # requirements > multi # my system's Python library is threaded > python2.3 > boost_python > ; > > which imports sha without incident. Except it doesn't set the include > path, so the same jamfile won't both compile my code and link it. So now > I just have to work out the arguments to get it to link with the shared > library and set the include path properly... perplexing. > > Thanks for any advice, The embedding example in libs/python/test/Jamfile looks like: run ../test/embedding.cpp ../build/boost_python : # program args : # input files : # requirements $(PYTHON_PROPERTIES) BOOST_PYTHON_STATIC_LIB BOOST_PYTHON_STATIC_MODULE $(PYTHON_LIB_PATH) <$(gcc-compilers)>$(CYGWIN_PYTHON_DEBUG_DLL_PATH) <$(gcc-compilers)><*>$(CYGWIN_PYTHON_DLL_PATH) $(PYTHON_EMBEDDED_LIBRARY) BOOST_PYTHON_STATIC_LIB is not needed if you're using the shared version of Boost.Python. You can use @boost/libs/python/build/boost_python if you are using the cross-project dependencies to ensure that the right shared library is built and linked in. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Mar 21 10:18:16 2005 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 21 Mar 2005 04:18:16 -0500 Subject: [C++-sig] Re: cross-module RTTI issues References: <200503142132.32051.dan@theproverbial.com> Message-ID: Dan Haffey writes: > Is there a way around this behavior, or is there just no hope for > this pattern of shared library usage? Any help would be greatly > appreciated, It's hard for me to say anything useful without knowing: a. What code got generated by pyste for doing these bindings b. Where your shared library boundaries are. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Mar 21 10:25:03 2005 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 21 Mar 2005 04:25:03 -0500 Subject: [C++-sig] Re: Problems with dynamic casts References: <4238A15F.5090507@panoramicfeedback.com> Message-ID: Aaron Bentley writes: > Okay, here's some stripped down examples: > > ---foo.h--- > class BaseClass > { > public: > BaseClass() > {} > virtual ~BaseClass() > {} > }; > > ---foo.cpp--- > ... ^^^ That's not very useful; it produces a syntax error. Please post something that compiles. > > Everything except wrapper.cpp is built as one shared library. And how is wrapper.cpp built? How about just posting a Jamfile? > When I run test.py, I get this: > Testing SubClass > If I change the constructor for SubClass to an inline constructor I can tell you that in many compilers, RTTI information typically gets generated where a class' first non-inline function is defined. > , I get > this: How about reducing your python test program to something that does a single operation that causes an assertion to fire? Trying to figure out what you think the behavior ought to be from all this output is going to be hard. > So it seems I can't do implicit dynamic casts (passing a base-class > pointer to a function taking a subclass pointer) and explicit > dynamic casts at the same time. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Mar 21 10:27:34 2005 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 21 Mar 2005 04:27:34 -0500 Subject: [C++-sig] Re: Embedded Python plus module loading References: <423DF74B.7060101@fastmail.fm> Message-ID: Daniel Holth writes: > Okay, I've put a minimal example together. > > http://dingoskidneys.com/~dholth/minimal-embedding-failure.zip > > It is the embedding example from boost, with an "import sha" statement > added inside it. sha depends on some dynamically loaded code. When I try > to run it, it says: > > ImportError: /usr/lib/python2.3/lib-dynload/sha.so: undefined symbol: > Py_FindMethod You should post this question on comp.lang.python; it's really not a Boost-related problem. I'm sure someone there knows how to deal with it. -- Dave Abrahams Boost Consulting www.boost-consulting.com From yaoheling at yahoo.com Mon Mar 21 15:33:37 2005 From: yaoheling at yahoo.com (Yao Heling) Date: Mon, 21 Mar 2005 06:33:37 -0800 (PST) Subject: [C++-sig] Re: Embedded Python plus module loading Message-ID: <20050321143338.48193.qmail@web40805.mail.yahoo.com> if my memory serves me right, I had a similar problem once. One has to include Python.h or Boost.python headers before other headers are included. or change the linking order of shared libs. Hope that helps. Joseph H. Yao On Mon, Mar 21, 2005 at 04:27:34AM -0500, David Abrahams wrote: > Daniel Holth writes: > > > Okay, I've put a minimal example together. > > > > http://dingoskidneys.com/~dholth/minimal-embedding-failure.zip > > > > It is the embedding example from boost, with an "import sha" statement > > added inside it. sha depends on some dynamically loaded code. When I try > > to run it, it says: > > > > ImportError: /usr/lib/python2.3/lib-dynload/sha.so: undefined symbol: > > Py_FindMethod > > You should post this question on comp.lang.python; it's really not a > Boost-related problem. I'm sure someone there knows how to deal with > it. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From dave at boost-consulting.com Mon Mar 21 16:10:17 2005 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 21 Mar 2005 10:10:17 -0500 Subject: [C++-sig] Re: Embedded Python plus module loading References: <20050321143338.48193.qmail@web40805.mail.yahoo.com> Message-ID: Yao Heling writes: > if my memory serves me right, I had a similar problem > once. One has to > include Python.h or Boost.python headers before other > headers are > included. Actually the latter. Although I'm not sure this is related to any linking problems. > or change the linking order of shared libs. That's quite plausible. -- Dave Abrahams Boost Consulting www.boost-consulting.com From abentley at panoramicfeedback.com Mon Mar 21 16:51:04 2005 From: abentley at panoramicfeedback.com (Aaron Bentley) Date: Mon, 21 Mar 2005 10:51:04 -0500 Subject: [C++-sig] Re: Problems with dynamic casts In-Reply-To: References: <4238A15F.5090507@panoramicfeedback.com> Message-ID: <423EED68.7010907@panoramicfeedback.com> David Abrahams wrote: > ^^^ > That's not very useful; it produces a syntax error. Please post > something that compiles. This will take a while, since I'm not familiar with building shared libraries, except by letting autoconf/automake do it. >>Everything except wrapper.cpp is built as one shared library. > > > And how is wrapper.cpp built? > How about just posting a Jamfile? I can do that, but again I'd have to create a new Jamfile. > How about reducing your python test program to something that does a > single operation that causes an assertion to fire? Trying to figure > out what you think the behavior ought to be from all this output is > going to be hard. There are three things that go wrong: 1. calling a function that takes a pointer/reference to the SubClass with a BaseClass& that refers to a SubClass 2. dynamically casting from BaseClass 3. dynamically casting from SubClass The behavior ought to be: Testing SubClass subcl can be passed to test_subclass directly subcl can be passed to test_subclass when returned as a base class subcl can be dynamically cast from subclass subcl can be dynamically cast from base class Although I've been able to get the test cases to do that, I've been unable to get the real code to do that. Aaron -- Aaron Bentley Director of Technology Panometrics, Inc. From abentley at panoramicfeedback.com Mon Mar 21 16:51:04 2005 From: abentley at panoramicfeedback.com (Aaron Bentley) Date: Mon, 21 Mar 2005 10:51:04 -0500 Subject: [C++-sig] Re: Problems with dynamic casts In-Reply-To: References: <4238A15F.5090507@panoramicfeedback.com> Message-ID: <423EED68.7010907@panoramicfeedback.com> David Abrahams wrote: > ^^^ > That's not very useful; it produces a syntax error. Please post > something that compiles. This will take a while, since I'm not familiar with building shared libraries, except by letting autoconf/automake do it. >>Everything except wrapper.cpp is built as one shared library. > > > And how is wrapper.cpp built? > How about just posting a Jamfile? I can do that, but again I'd have to create a new Jamfile. > How about reducing your python test program to something that does a > single operation that causes an assertion to fire? Trying to figure > out what you think the behavior ought to be from all this output is > going to be hard. There are three things that go wrong: 1. calling a function that takes a pointer/reference to the SubClass with a BaseClass& that refers to a SubClass 2. dynamically casting from BaseClass 3. dynamically casting from SubClass The behavior ought to be: Testing SubClass subcl can be passed to test_subclass directly subcl can be passed to test_subclass when returned as a base class subcl can be dynamically cast from subclass subcl can be dynamically cast from base class Although I've been able to get the test cases to do that, I've been unable to get the real code to do that. Aaron -- Aaron Bentley Director of Technology Panometrics, Inc. From dholth at fastmail.fm Mon Mar 21 18:35:33 2005 From: dholth at fastmail.fm (Daniel Holth) Date: Mon, 21 Mar 2005 12:35:33 -0500 Subject: [C++-sig] Re: Embedded Python plus module loading In-Reply-To: References: <423DF74B.7060101@fastmail.fm> Message-ID: <1111426533.21146.230068657@webmail.messagingengine.com> My problem means boost.build doesn't know how to properly link my embedded Python program. I can add that same line "import sha" to /libs/python/test/embedding.cpp, build it with 'bjam embedding', and the test fails to run properly. According to the ld manual page I need to use --export-dynamic to expose symbols coming from static parts of my binary (like the static libpython boost.build likes to link to) to dynamic libraries like imported python modules. Or I can just dynamically link libpython I haven't sufficiently decoded boost.build to figure out how to change the library search path to prefer the dynamically loaded Python library xor add the linker option --export-dynamic, I would prefer to just dynamically link libpython and it would be nice to keep boost's handy Python version finder. Thanks for any help, Daniel Holth From abentley at panoramicfeedback.com Mon Mar 21 20:05:35 2005 From: abentley at panoramicfeedback.com (Aaron Bentley) Date: Mon, 21 Mar 2005 14:05:35 -0500 Subject: [C++-sig] Re: Problems with dynamic casts In-Reply-To: References: <4238A15F.5090507@panoramicfeedback.com> Message-ID: David Abrahams wrote: > I can tell you that in many compilers, RTTI information typically gets > generated where a class' first non-inline function is defined. Ah! That's very helpful. I'd assumed there was something special about constructors, but it was just a question of whether the class had *any* non-inline functions. I was at least able to get dynamic casting working, so I can do some ugly wrapping and get on with this project. Thanks! Aaron -- Aaron Bentley Director of Technology Panometrics, Inc. From dhaffey at gmail.com Mon Mar 21 23:35:38 2005 From: dhaffey at gmail.com (Dan Haffey) Date: Mon, 21 Mar 2005 22:35:38 +0000 Subject: [C++-sig] Re: cross-module RTTI issues In-Reply-To: References: <200503142132.32051.dan@theproverbial.com> Message-ID: <5ab87402050321143577c8aaa4@mail.gmail.com> > It's hard for me to say anything useful without knowing: > > a. What code got generated by pyste for doing these bindings > b. Where your shared library boundaries are. Oh, sorry, I should have said something in this thread as well... it turned out my problems actually had less to do with linking than with forgetting to call Import in my Pyste files (there's a lesson in checking the actual Boost C++ calls if I've ever received one). Once I took care of that, I did actually run into some linking issues, but these were easily solved by putting the first virtual function of each of the offending classes into a common library as mentioned in the Wiki node. Sorry to waste your time, and thanks for your help and the great library! -- Dan Haffey From jesper.olsen at gmail.com Tue Mar 22 05:17:21 2005 From: jesper.olsen at gmail.com (Jesper Olsen) Date: Tue, 22 Mar 2005 06:17:21 +0200 Subject: [C++-sig] Re: hello.pyd - where did it go? In-Reply-To: References: <4239A70C.6090406@boost-consulting.com> Message-ID: On Sun, 20 Mar 2005 15:42:01 -0500, David Abrahams wrote: > Jesper Olsen writes: > > > Anyway - I'm glad it's working now. > > I think the python bridge is very cool - much easier than writing the > > usual c interface files. > > However - installation and distribution of code is less streamlined > > than using python distutils - but I guess it was not the intention to > > replace that anyway. > > Well, it is our intention to fully replace distutils for the purposes > of C++, very soon. And distutils was very bad at dealing with C++ > last time I looked. I'm glad to hear that. Nevertheless - boost is very big - much bigger than c-python. I put it on a webserver, where it made a serious dent in the harddisk space. Distutils is not great as a build environment - but you can tell it to eg. use g++ as the linker - so that your extension can be in C++ as long as the python interface is C... But one thing I find frustrating is that it shields you from platform specific details - making it very hard to e.g. pass "unusual" options to the compiler etc. The good thing about disutils though is that it is very easy to give your source code to someone else - and they will be able to install it and use with very little fuss. Cheers Jesper From colin_irwin at hotmail.com Tue Mar 22 07:56:21 2005 From: colin_irwin at hotmail.com (Colin Irwin) Date: Tue, 22 Mar 2005 17:56:21 +1100 Subject: [C++-sig] Re: Wrapper for exception translation In-Reply-To: <2040C0A1CA23D51181A30050BAAC9902011046D8@berexch.ber.haufemg.com> References: <2040C0A1CA23D51181A30050BAAC9902011046D8@berexch.ber.haufemg.com> Message-ID: I need to be able to translate custom C++ exceptions into similar Python entities, so was looking through the newsgroup for tips. In particular, I would like the translated exceptions to be derived off Exception and not be limited to one of the already provided exceptions types. I found this thread and am interested, as it seems to offer exactly the functionality required. What is the status of this functionality? If some finishing of the implementation is required, then I'm prepared to have a look. Can't say for 100% that I'll be able to do it - but I'll have a look. 8^) Colin From yaoheling at yahoo.com Tue Mar 22 10:19:46 2005 From: yaoheling at yahoo.com (Yao Heling) Date: Tue, 22 Mar 2005 01:19:46 -0800 (PST) Subject: [C++-sig] Re: Embedded Python plus module loading Message-ID: <20050322091946.48208.qmail@web40829.mail.yahoo.com> I've never used bjam but the following link may be of help. http://www.python.org/moin/boost.python/BuildingExtensions you can try scons as well, which I found to be easier to use. Regards, Joseph H. Yao On Mon, Mar 21, 2005 at 12:35:33PM -0500, Daniel Holth wrote: > My problem means boost.build doesn't know how to properly link my > embedded Python program. I can add that same line "import sha" to > /libs/python/test/embedding.cpp, build it with 'bjam embedding', and the > test fails to run properly. > > According to the ld manual page I need to use --export-dynamic to expose > symbols coming from static parts of my binary (like the static libpython > boost.build likes to link to) to dynamic libraries like imported python > modules. Or I can just dynamically link libpython > > I haven't sufficiently decoded boost.build to figure out how to change > the library search path to prefer the dynamically loaded Python library > xor add the linker option --export-dynamic, I would prefer to just > dynamically link libpython and it would be nice to keep boost's handy > Python version finder. > > Thanks for any help, > > Daniel Holth > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From nicodemus at esss.com.br Tue Mar 22 13:45:50 2005 From: nicodemus at esss.com.br (Nicodemus) Date: Tue, 22 Mar 2005 09:45:50 -0300 Subject: [C++-sig] Re: Wrapper for exception translation In-Reply-To: References: <2040C0A1CA23D51181A30050BAAC9902011046D8@berexch.ber.haufemg.com> Message-ID: <4240137E.6080002@esss.com.br> Hi, Colin Irwin wrote: > I need to be able to translate custom C++ exceptions into similar > Python entities, so was looking through the newsgroup for tips. In > particular, I would like the translated exceptions to be derived off > Exception and not be limited to one of the already provided exceptions > types. I found this thread and am interested, as it seems to offer > exactly the functionality required. > What is the status of this functionality? If some finishing of the > implementation is required, then I'm prepared to have a look. Can't > say for 100% that I'll be able to do it - but I'll have a look. 8^) I guess you could use *PyErr_NewException with the standard boost::python way of translating exceptions. Take a look at the tutorial and the Python C API section of the python documentation. Regards, Nicodemus. * From dave at boost-consulting.com Tue Mar 22 15:48:15 2005 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 22 Mar 2005 09:48:15 -0500 Subject: [C++-sig] Re: Wrapper for exception translation References: <2040C0A1CA23D51181A30050BAAC9902011046D8@berexch.ber.haufemg.com> Message-ID: Colin Irwin writes: > I need to be able to translate custom C++ exceptions into similar Python > entities, so was looking through the newsgroup for tips. In particular, > I would like the translated exceptions to be derived off Exception and > not be limited to one of the already provided exceptions types. I found > this thread and am interested, as it seems to offer exactly the > functionality required. > What is the status of this functionality? If some finishing of the > implementation is required, then I'm prepared to have a look. Can't say > for 100% that I'll be able to do it - but I'll have a look. 8^) It's easy enough to implement the guts. What happened is that it became clear I needed unnamed parameter support (like .def, where parameters can come in any order) in order to implement a good interface. I started to look into extending the named parameters library (http://article.gmane.org/gmane.comp.lib.boost.announce/54, http://article.gmane.org/gmane.comp.lib.boost.announce/55) to support unnamed parameters, and got stuck because I didn't understand the code anymore (partly my own forgetfulness, partly the code itself). Daniel Wallin, the library's co-author was going to try to clear things up. Since then, I'm not sure what's happened. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Tue Mar 22 16:04:47 2005 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 22 Mar 2005 10:04:47 -0500 Subject: [C++-sig] Re: Embedded Python plus module loading References: <20050322091946.48208.qmail@web40829.mail.yahoo.com> Message-ID: Yao Heling writes: > I've never used bjam but the following link may be of > help. > > http://www.python.org/moin/boost.python/BuildingExtensions Unfortunately, both that Wiki page and the Boost.Python tutorial are a little out-of-date. While that procedure will work, it's awkward to build from within the Boost tree. A much better set of instructions can be found by looking at libs/python/example/ in your Boost installation. Start with the README file, and then follow the comments in the files it references. Joel, can you look into updating the tutorial so that it reflects the availability of cross-module building? Mike, it would be good to get the Wiki updated as well. In fact, I have a real concern about the cost of maintaining what looks like duplicate information in the Wiki and the official tutorial. I just had to fix a link to the tutorial in the Wiki, but this redundancy seems like a bad idea overall. Mike, I'd be happy to make you a co-maintainer of the tutorial, so that any time you wanted to add something, you could do so. Then we could replace the Wiki pages with a link to the tutorial. Make sense? -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Tue Mar 22 16:07:51 2005 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 22 Mar 2005 10:07:51 -0500 Subject: [C++-sig] Re: hello.pyd - where did it go? References: <4239A70C.6090406@boost-consulting.com> Message-ID: Jesper Olsen writes: > On Sun, 20 Mar 2005 15:42:01 -0500, David Abrahams > wrote: >> Jesper Olsen writes: >> Well, it is our intention to fully replace distutils for the purposes >> of C++, very soon. And distutils was very bad at dealing with C++ >> last time I looked. > > I'm glad to hear that. Nevertheless - boost is very big - much > bigger than c-python. I put it on a webserver, where it made a > serious dent in the harddisk space. I'm not sure what you're getting at, but Boost.Build is an independent component that can be used without the rest of Boost. > Distutils is not great as a build environment - but you can tell it to > eg. use g++ as the linker - so that your extension can be in C++ as > long as the python interface is C... Assuming you are using g++. But how is it at doing C++ on other compilers without a lot of user intervention? That was one of the big problems last I looked. > But one thing I find frustrating is that it shields you from > platform specific details - making it very hard to e.g. pass > "unusual" options to the compiler etc. Boost.Build also shields you, but there are plenty of "backdoor" escapes to help you around such limitations when neccessary. > The good thing about disutils though is that it is very easy to give > your source code to someone else - and they will be able to install > it and use with very little fuss. We're hoping that will be the case with Boost.Build very soon. Even more so once the Python rewrite is done ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com From Paul_Kunz at slac.stanford.edu Tue Mar 22 22:57:02 2005 From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz) Date: Tue, 22 Mar 2005 13:57:02 -0800 Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual function In-Reply-To: (message from David Abrahams on Sun, 12 Dec 2004 22:26:21 -0500) References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu> <200412082014.iB8KELf13038@libra3.slac.stanford.edu> <200412122133.iBCLXwB21886@libra3.slac.stanford.edu> Message-ID: <200503222157.j2MLv2n32361@libra3.slac.stanford.edu> Some time ago, I got this work under Linux with both gcc 2.95.3 and gcc 3.4.3. Now I'm testing under Windows with VC++ 7.1 and having trouble. The first part of the wrapping code is... using namespace boost::python; namespace hippodraw { namespace Python { void export_FunctionBase () { class_ < FunctionWrap, std::auto_ptr < FunctionWrap> > ( "FunctionBase", init < const FunctionBase & > () ) // line with error .def ( init < const FunctionWrap & > () ) .def ( init <> () ) .def ( "initialize", &FunctionWrap::initialize ) .def ( "name", &FunctionBase::name, return_value_policy < copy_const_reference > () ) .def ( "setName", &FunctionWrap::setName ) The VC++ build log is attached below and is saying can't instanciate FunctionBase because pure virtual functions have no definition. These functions are defined in FunctionWrap. Is this possibly a problem with VC++ or is gcc letting me get away with something. Build Log ------- Build started: Project: pyhippo, Configuration: ReleaseAll|Win32 ------- Command Lines Creating temporary file "c:\hippodraw\vs.net2003\pyhippo\ReleaseAll\RSP000012.rsp" with contents [ /O2 /I "..\qthippo" /I "..\..\qt" /I "..\.." /I "C:\Qt\3.3.3\include" /I "C:\Boost\include\boost-1_32" /I "c:\Python24\include" /I "C:\Minuit" /I "C:\cfitsio" /D "WIN32" /D "NDEBUG" /D "QT_THREAD_SUPPORT" /D "HAVE_MINUIT" /D "HAVE_ROOT" /D "MDL_HIPPOPLOT_IMPORTS" /D "_WINDLL" /D "_MBCS" /FD /EHsc /MD /GR /Fo"ReleaseAll/" /Fd"ReleaseAll/vc70.pdb" /W3 /c /TP /wd4251 \hippodraw\python\ObserverWrap.cxx ] Creating command line "cl.exe @c:\hippodraw\vs.net2003\pyhippo\ReleaseAll\RSP000012.rsp /nologo" Creating temporary file "c:\hippodraw\vs.net2003\pyhippo\ReleaseAll\RSP000013.rsp" with contents [ /O2 /I "..\qthippo" /I "..\..\qt" /I "..\.." /I "C:\Qt\3.3.3\include" /I "C:\Boost\include\boost-1_32" /I "c:\Python24\include" /I "C:\Minuit" /I "C:\cfitsio" /D "WIN32" /D "NDEBUG" /D "QT_THREAD_SUPPORT" /D "HAVE_MINUIT" /D "HAVE_ROOT" /D "MDL_HIPPOPLOT_IMPORTS" /D "_WINDLL" /D "_MBCS" /FD /EHsc /MD /GR /Fo"ReleaseAll/" /Fd"ReleaseAll/vc70.pdb" /W3 /c /TP /wd4251 \hippodraw\python\FunctionWrap.cxx ] Creating command line "cl.exe @c:\hippodraw\vs.net2003\pyhippo\ReleaseAll\RSP000013.rsp /nologo" Output Window Compiling... ObserverWrap.cxx Compiling... FunctionWrap.cxx C:\Boost\include\boost-1_32\boost\python\converter\as_to_python_function.hpp(21) : error C2259: 'FunctionBase' : cannot instantiate abstract class due to following members: 'double FunctionBase::derivByParm(int,double) const' : pure virtual function was not defined ..\..\functions\FunctionBase.h(134) : see declaration of 'FunctionBase::derivByParm' 'void FunctionBase::initialize(void)' : pure virtual function was not defined ..\..\functions\FunctionBase.h(165) : see declaration of 'FunctionBase::initialize' 'double FunctionBase::operator ()(double) const' : pure virtual function was not defined ..\..\functions\FunctionBase.h(254) : see declaration of 'FunctionBase::operator`()'' C:\Boost\include\boost-1_32\boost\python\to_python_converter.hpp(34) : see reference to class template instantiation 'boost::python::converter::as_to_python_function' being compiled with [ T=FunctionBase, ToPython=boost::python::objects::class_cref_wrapper,boost::python::detail::not_specified,boost::python::detail::not_specified>::holder>> ] C:\Boost\include\boost-1_32\boost\detail\compressed_pair.hpp(200) : while compiling class-template member function 'boost::python::to_python_converter::to_python_converter(void)' with [ T=FunctionBase, Conversion=boost::python::objects::class_cref_wrapper,boost::python::detail::not_specified,boost::python::detail::not_specified>::holder>> ] C:\Boost\include\boost-1_32\boost\python\object\class_wrapper.hpp(23) : see reference to class template instantiation 'boost::python::to_python_converter' being compiled with [ T=FunctionBase, Conversion=boost::python::objects::class_cref_wrapper,boost::python::detail::not_specified,boost::python::detail::not_specified>::holder>> ] C:\Boost\include\boost-1_32\boost\python\object\class_metadata.hpp(248) : see reference to class template instantiation 'boost::python::objects::class_cref_wrapper' being compiled with [ Src=FunctionBase, MakeInstance=boost::python::objects::make_instance,boost::python::detail::not_specified,boost::python::detail::not_specified>::holder> ] C:\Boost\include\boost-1_32\boost\python\object\class_metadata.hpp(218) : see reference to function template instantiation 'void boost::python::objects::class_metadata::maybe_register_class_to_python(T2 *,boost::mpl::false_)' being compiled with [ T=FunctionWrap, X1=std::auto_ptr, X2=boost::python::detail::not_specified, X3=boost::python::detail::not_specified, T2=FunctionBase ] C:\Boost\include\boost-1_32\boost\python\object\class_metadata.hpp(202) : see reference to function template instantiation 'void boost::python::objects::class_metadata::register_aux2>(T2 *,Callback)' being compiled with [ T=FunctionWrap, X1=std::auto_ptr, X2=boost::python::detail::not_specified, X3=boost::python::detail::not_specified, T2=FunctionBase, C_=true, Callback=boost::mpl::bool_ ] C:\Boost\include\boost-1_32\boost\python\object\class_metadata.hpp(195) : see reference to function template instantiation 'void boost::python::objects::class_metadata::register_aux(boost::python::wrapper *)' being compiled with [ T=FunctionWrap, X1=std::auto_ptr, X2=boost::python::detail::not_specified, X3=boost::python::detail::not_specified ] C:\Boost\include\boost-1_32\boost\python\object\class_metadata.hpp(194) : while compiling class-template member function 'void boost::python::objects::class_metadata::register_(void)' with [ T=FunctionWrap, X1=std::auto_ptr, X2=boost::python::detail::not_specified, X3=boost::python::detail::not_specified ] C:\Boost\include\boost-1_32\boost\python\class.hpp(174) : see reference to class template instantiation 'boost::python::objects::class_metadata' being compiled with [ T=FunctionWrap, X1=std::auto_ptr, X2=boost::python::detail::not_specified, X3=boost::python::detail::not_specified ] C:\Boost\include\boost-1_32\boost\python\class.hpp(205) : see reference to class template instantiation 'boost::python::class_::id_vector' being compiled with [ W=FunctionWrap, X1=std::auto_ptr ] \hippodraw\python\FunctionWrap.cxx(27) : see reference to function template instantiation 'boost::python::class_::class_>(const char *,const boost::python::init_base &)' being compiled with [ W=FunctionWrap, X1=std::auto_ptr, T0=const FunctionBase &, DerivedT=boost::python::init ] Results Build log was saved at "file://c:\hippodraw\vs.net2003\pyhippo\ReleaseAll\BuildLog.htm" pyhippo - 1 error(s), 0 warning(s) Complete source code can be browsed here ... http://www.slac.stanford.edu/grp/ek/hippodraw From dave at boost-consulting.com Tue Mar 22 23:57:49 2005 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 22 Mar 2005 17:57:49 -0500 Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual function References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu> <200412082014.iB8KELf13038@libra3.slac.stanford.edu> <200412122133.iBCLXwB21886@libra3.slac.stanford.edu> <200503222157.j2MLv2n32361@libra3.slac.stanford.edu> Message-ID: "Paul F. Kunz" writes: > Some time ago, I got this work under Linux with both gcc 2.95.3 and > gcc 3.4.3. Now I'm testing under Windows with VC++ 7.1 and having > trouble. > > The first part of the wrapping code is... > > using namespace boost::python; > > namespace hippodraw { > namespace Python { > void > export_FunctionBase () > { > class_ < FunctionWrap, std::auto_ptr < FunctionWrap> > > ( "FunctionBase", init < const FunctionBase & > () ) // line with error > .def ( init < const FunctionWrap & > () ) > .def ( init <> () ) > .def ( "initialize", &FunctionWrap::initialize ) > .def ( "name", &FunctionBase::name, > return_value_policy < copy_const_reference > () ) > .def ( "setName", &FunctionWrap::setName ) > > The VC++ build log is attached below Was it filtered by something? I can't see much of the information I'm used to getting from VC++ there. > and is saying can't instanciate FunctionBase because pure virtual > functions have no definition. These functions are defined in > FunctionWrap. Is this possibly a problem with VC++ or is gcc > letting me get away with something. Looks like a VC++ problem, though I don't know for sure. Is FunctionWrap copyable? Otherwise you should use noncopyable in its class_ and these errors might disappear. -- Dave Abrahams Boost Consulting www.boost-consulting.com From nicodemus at esss.com.br Tue Mar 22 23:11:24 2005 From: nicodemus at esss.com.br (Nicodemus) Date: Tue, 22 Mar 2005 20:11:24 -0200 Subject: [C++-sig] Re: hello.pyd - where did it go? In-Reply-To: References: <4239A70C.6090406@boost-consulting.com> Message-ID: <4240980C.1070604@esss.com.br> David Abrahams wrote: >Jesper Olsen writes: > > >>The good thing about disutils though is that it is very easy to give >>your source code to someone else - and they will be able to install >>it and use with very little fuss. >> >> > >We're hoping that will be the case with Boost.Build very soon. Even >more so once the Python rewrite is done ;-) > > I might be wrong, but I believe you said once that one of the design decisions about Boost.Build was that it shouldn't depend on other software; that's the reason (I believe) SCons couldn't be considered as a replacement, since it depends on Python. Has this decision changed? Very nice to hear about the Python port, btw. :) Regards, Nicodemus. From Paul_Kunz at slac.stanford.edu Wed Mar 23 00:50:35 2005 From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz) Date: Tue, 22 Mar 2005 15:50:35 -0800 Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual function In-Reply-To: (message from David Abrahams on Tue, 22 Mar 2005 17:57:49 -0500) References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu> <200412082014.iB8KELf13038@libra3.slac.stanford.edu> <200412122133.iBCLXwB21886@libra3.slac.stanford.edu> <200503222157.j2MLv2n32361@libra3.slac.stanford.edu> Message-ID: <200503222350.j2MNoZ700448@libra3.slac.stanford.edu> >>>>> On Tue, 22 Mar 2005 17:57:49 -0500, David Abrahams said: >> >> The VC++ build log is attached below > Was it filtered by something? I can't see much of the information > I'm used to getting from VC++ there. No, just converted from html to plain text. >> and is saying can't instanciate FunctionBase because pure virtual >> functions have no definition. These functions are defined in >> FunctionWrap. Is this possibly a problem with VC++ or is gcc >> letting me get away with something. > Looks like a VC++ problem, though I don't know for sure. Is > FunctionWrap copyable? Didn't we have to make it copyable so that clone member function could be implemented in Python? > Otherwise you should use noncopyable in its > class_ and these errors might disappear. I'll try, but not right away. From dholth at fastmail.fm Wed Mar 23 01:25:22 2005 From: dholth at fastmail.fm (Daniel Holth) Date: Tue, 22 Mar 2005 19:25:22 -0500 Subject: [C++-sig] Re: Embedded Python plus module loading In-Reply-To: References: <20050322091946.48208.qmail@web40829.mail.yahoo.com> Message-ID: <1111537522.27305.3.camel@bluefish> On Tue, 2005-03-22 at 10:04 -0500, David Abrahams wrote: > Yao Heling writes: > > > I've never used bjam but the following link may be of > > help. > > > > http://www.python.org/moin/boost.python/BuildingExtensions > > Unfortunately, both that Wiki page and the Boost.Python tutorial are a > little out-of-date. While that procedure will work, it's awkward to > build from within the Boost tree. A much better set of instructions > can be found by looking at libs/python/example/ in your Boost > installation. Start with the README file, and then follow the > comments in the files it references. That is certainly unfortunate. As you can see, for some reason posting my questions to this list helps me to figure out the solution for myself. My solution to the symbol resolution problem is to remove /usr/lib/python2.3/config/ (where the static libpython lives) from the library search path. Right now I just edit boost's python.jam but I'm sure there is a way to do this without doing that. Without static libpython in the search path, my program happily links with the shared libpython in /usr/lib, all symbols are resolved, my embedded Python does what it is supposed to do. Thanks all, Daniel Holth -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kalin.eh at gmail.com Wed Mar 23 03:55:57 2005 From: kalin.eh at gmail.com (kalin) Date: Wed, 23 Mar 2005 12:55:57 +1000 Subject: [C++-sig] Exposing BOOST_STRONG_TYPEDEF types. Message-ID: Hi all, I have some types that I have created with BOOST_STRONG_TYPEDEF. I want to manipulate these types from Python, but given that they are not built-in data types, Boost.Python cannot implicitly handle them. So what I want to do is, given BOOST_STRONG_TYPEDEF(size_t, ID) for example, expose this as an 'int'. I suppose you would want to do something like: class_ >("ID"); It seems you can derive from a built-in data type in Python, I'm not sure what this actually does to the class though. (not a python expert :) ) Does anyone know if there is a 'proper' way to do this with Boost.Python? kalin From dave at boost-consulting.com Wed Mar 23 05:10:16 2005 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 22 Mar 2005 23:10:16 -0500 Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual function References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu> <200412082014.iB8KELf13038@libra3.slac.stanford.edu> <200412122133.iBCLXwB21886@libra3.slac.stanford.edu> <200503222157.j2MLv2n32361@libra3.slac.stanford.edu> <200503222350.j2MNoZ700448@libra3.slac.stanford.edu> Message-ID: "Paul F. Kunz" writes: >>>>>> On Tue, 22 Mar 2005 17:57:49 -0500, David Abrahams said: > >>> >>> The VC++ build log is attached below > >> Was it filtered by something? I can't see much of the information >> I'm used to getting from VC++ there. > > No, just converted from html to plain text. Try building from the command-line; you'll see more. >>> and is saying can't instanciate FunctionBase because pure virtual >>> functions have no definition. These functions are defined in >>> FunctionWrap. Is this possibly a problem with VC++ or is gcc >>> letting me get away with something. > >> Looks like a VC++ problem, though I don't know for sure. Is >> FunctionWrap copyable? > > Didn't we have to make it copyable so that clone member function > could be implemented in Python? I don't know what you had to do, and if I helped you with this code in the past I don't remember it. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Wed Mar 23 05:10:44 2005 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 22 Mar 2005 23:10:44 -0500 Subject: [C++-sig] Re: hello.pyd - where did it go? References: <4239A70C.6090406@boost-consulting.com> <4240980C.1070604@esss.com.br> Message-ID: Nicodemus writes: > David Abrahams wrote: > >>Jesper Olsen writes: >> >> >>>The good thing about disutils though is that it is very easy to give >>>your source code to someone else - and they will be able to install >>>it and use with very little fuss. >>> >>> >> >>We're hoping that will be the case with Boost.Build very soon. Even >>more so once the Python rewrite is done ;-) >> >> > > I might be wrong, but I believe you said once that one of the design > decisions about Boost.Build was that it shouldn't depend on other > software; that's the reason (I believe) SCons couldn't be considered as > a replacement, since it depends on Python. Has this decision > changed? It seems so. > Very nice to hear about the Python port, btw. :) It's already been started. -- Dave Abrahams Boost Consulting www.boost-consulting.com From colin_irwin at hotmail.com Wed Mar 23 08:15:26 2005 From: colin_irwin at hotmail.com (Colin Irwin) Date: Wed, 23 Mar 2005 18:15:26 +1100 Subject: [C++-sig] Re: Wrapper for exception translation In-Reply-To: References: <2040C0A1CA23D51181A30050BAAC9902011046D8@berexch.ber.haufemg.com> Message-ID: Dave - where do you recommend that I start looking at this one? I understand what has been discussed as part of this thread and I'll have a look at the named parameters library as you suggest. I just don't want to have to start from the beginning, if a fine start has already been done / exists somewhere. From ghost at cs.msu.su Wed Mar 23 09:31:40 2005 From: ghost at cs.msu.su (Vladimir Prus) Date: Wed, 23 Mar 2005 11:31:40 +0300 Subject: [C++-sig] Re: 'numpy' test broken? References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com> Message-ID: Ralf W. Grosse-Kunstleve wrote: >> Hello, >> using fresh CVS state, I get failure of the 'numpy' test. I run: >> >> bjam -sPYTHON_ROOT=/usr -sPYTHON_VERSION=2.3 numpy >> >> and get error. The interesting part of the test output is: > > I just checked in a workaround (numpy.py in test directory): > # Unfortunately the doctest module works differently in Python versions > # 2.2, 2.3, and 2.4. Newer versions evaluate all docstrings, even that > # of objects with names starting with an underscore. To portably disable > # tests based on the availability of Numeric and Numpy, the corresponding > # test functions are simply deleted below if necessary. > > It is not a perfect fix since newer versions of Python's doctest module > examine functions that we do not want to have examined, leading to > spurious output, but that's all I have time for and the nasty long error > messages are gone at least. Thank you! - Volodya From dave at boost-consulting.com Wed Mar 23 16:18:57 2005 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 23 Mar 2005 10:18:57 -0500 Subject: [C++-sig] Re: Wrapper for exception translation References: <2040C0A1CA23D51181A30050BAAC9902011046D8@berexch.ber.haufemg.com> Message-ID: Colin Irwin writes: > Dave - where do you recommend that I start looking at this one? > > I understand what has been discussed as part of this thread and I'll > have a look at the named parameters library as you suggest. I wasn't suggesting that. > I just don't want to have to start from the beginning, if a fine > start has already been done / exists somewhere. I suggest you wait a week or so. Daniel has promised to finish cleaning up and commenting that library in the next few days. After that we'll discuss how to add unnamed parameter support, and if we can do that quickly, within a few more days I can provide the ability to specify a Python base class. -- Dave Abrahams Boost Consulting www.boost-consulting.com From lothar at xcerla.com Wed Mar 23 20:26:40 2005 From: lothar at xcerla.com (Lothar Werzinger) Date: Wed, 23 Mar 2005 11:26:40 -0800 Subject: [C++-sig] boost::python (boost-1_32) and gcc 4.0 (compiler error) Message-ID: <200503231126.40967.lothar@xcerla.com> Hi, boost::python does not compile with gcc 4.0 (4.0-20050213). Has anyone successfully used boost::python and gcc 4.0? Are there patches to make it work? The error given is: /opt2/boost/include/boost-1_32/boost/mpl/aux_/integral_wrapper.hpp:72: error: template argument 2 is invalid /opt2/boost/include/boost-1_32/boost/mpl/aux_/integral_wrapper.hpp:73: error: template argument 2 is invalid Here's the complete compiler output: /opt2/GNU/bin/g++-4.0-20050213 -O0 -g -D_REENTRANT -DACE_HAS_AIO_CALLS -DACE_USE_RCSID=0 -DACE_HAS_EXCEPTIONS -DOTL_STL -DOTL_ORA10G -DOTL_ORA_TIMESTAMP -DOTL_STREAM_NO_PRIVATE_BOOL_OPERATORS -DOTL_STREAM_NO_PRIVATE_UNSIGNED_LONG_OPERATORS -W -Wall -Wpointer-arith -Wno-uninitialized -Woverloaded-virtual -Wcast-align -Wwrite-strings -Wcomments -march=pentiumpro -DCOVERAGE -fprofile-arcs -ftest-coverage -fPIC -Isrc -I/home/lothar/workspace3/tradescapeAPI -I/opt2/ACE_wrappers -I/opt2/ACE_wrappers/TAO -I/opt2/ACE_wrappers/TAO/orbsvcs -I/opt2/boost/include/boost-1_32 -I/opt2/python-2.4/include/python2.4 -I/opt2/log4cplus/include -I/opt2/otl4/include -I/opt2/oracle/product/10.1.0/client_1/rdbms/public -c -o src/utility/.build/posix/coverage/PythonScriptExecutor.os src/utility/PythonScriptExecutor.cpp In file included from /opt2/log4cplus/include/log4cplus/logger.h:20, from src/utility/PythonInterpreterGuard.h:12, from src/utility/PythonScriptExecutor.cpp:7: /opt2/log4cplus/include/log4cplus/config.h:79:1: warning: "HAVE_STAT" redefined In file included from /opt2/python-2.4/include/python2.4/Python.h:55, from /opt2/boost/include/boost-1_32/boost/python/detail/wrap_python.hpp:121, from /opt2/boost/include/boost-1_32/boost/python/detail/prefix.hpp:13, from /opt2/boost/include/boost-1_32/boost/python/args.hpp:8, from /opt2/boost/include/boost-1_32/boost/python.hpp:11, from src/utility/PythonInterpreterGuard.h:10, from src/utility/PythonScriptExecutor.cpp:7: /opt2/python-2.4/include/python2.4/pyport.h:139:1: warning: this is the location of the previous definition /opt2/boost/include/boost-1_32/boost/mpl/aux_/integral_wrapper.hpp:72: error: template argument 2 is invalid /opt2/boost/include/boost-1_32/boost/mpl/aux_/integral_wrapper.hpp:73: error: template argument 2 is invalid /opt2/boost/include/boost-1_32/boost/python/detail/wrapper_base.hpp:24: warning: unused parameter 'x' /opt2/boost/include/boost-1_32/boost/python/detail/wrapper_base.hpp:82: warning: unused parameter 'self' src/utility/PythonScriptExecutor.cpp: In constructor 'xcerla::utility::PythonScriptExecutor::PythonScriptExecutor()': src/utility/PythonScriptExecutor.cpp:41: warning: deprecated conversion from string constant to 'char*'' Lothar -- Lothar Werzinger Dipl.-Ing. Univ. framework & platform architect Xcerla Corporation 275 Tennant Avenue, Suite 202 Morgan Hill, Ca 95037 email: lothar at xcerla.com phone: +1-408-776-9018 From battelro at mail.msu.edu Wed Mar 23 20:33:09 2005 From: battelro at mail.msu.edu (Bob Battel) Date: Wed, 23 Mar 2005 14:33:09 -0500 Subject: [C++-sig] Herringshaw?? Message-ID: <6.1.2.0.0.20050323143031.01ead690@mail.msu.edu> Is this you? If you are the same Chris Herringshaw that I hung around with in Cass City, please reply. If not, I apologize for having wasted your time. Bob Battel Bob Battel Extension Educator, Farm Management Serving Northwest Lower Michigan Osceola MSU Extension 301 W. Upton Ave. Reed City, MI 49677 Phone: 231.832.7342 Please make a note new e-mail address: battelro at msu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From chencc at csie.nctu.edu.tw Thu Mar 24 10:35:29 2005 From: chencc at csie.nctu.edu.tw (chencc at csie.nctu.edu.tw) Date: Thu, 24 Mar 2005 17:35:29 +0800 (CST) Subject: [C++-sig] return_internal_reference or return_value_policy Message-ID: <200503240935.j2O9ZTux058980@mail.csie.nctu.edu.tw> Hi all: I have a small C code, and want to extent it using boost.python. This code return pointer and take pointer as argument. I try to use return_internal_reference or return_value_policy with manage_new_object. Then compiler can\'t give me a object code. I can\'t read these message, does any people can help me ??? I use the bjam in example/tutorial/Jamfile with modify in unix #include using namespace boost::python; typedef unsigned int *Handle; Handle cr(inti, Handle s) { Handle r; r = new unsigned int[i]; for ( int j = 0; j < i; j++) r[j] = s[j]; return r; } void dr(Handle s) { delete [] s; } void set(int i, Handle r) { r[i] = (unsigned int) i; } int get(int i, Handle r) { return r[i]; } BOOST_PYTHON_MODULE(my) { def(\"cr\",cr,return_value_policy< manage_new_object> () ); // def(\"cr\",cr,return_internal_reference<2> () ); def(\"dr\",dr); def(\"set\",set); def(\"get\",get); } } From rwgk at yahoo.com Fri Mar 25 15:53:53 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Fri, 25 Mar 2005 06:53:53 -0800 (PST) Subject: [C++-sig] boost::python (boost-1_32) and gcc 4.0 (compiler error) In-Reply-To: 6667 Message-ID: <20050325145353.84307.qmail@web31512.mail.mud.yahoo.com> --- Lothar Werzinger wrote: > boost::python does not compile with gcc 4.0 (4.0-20050213). > Has anyone successfully used boost::python and gcc 4.0? Are there patches to > make it work? I tried with - the latest boost CVS - gcc version 4.0.0 20050324 (prerelease) Most (i.e. all I tried) Boost.Python tests compile and even run. However, our applications are almost completely broken because of a show-stopper bug in gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317 Given this bug I am amazed that all Boost.Python tests run. In general I am afraid the current gcc 4.0.0 is unsuitable for real-world applications. :( Ralf __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs From faheem at email.unc.edu Fri Mar 25 22:46:43 2005 From: faheem at email.unc.edu (Faheem Mitha) Date: Fri, 25 Mar 2005 21:46:43 +0000 (UTC) Subject: [C++-sig] wrapping class with pure virtual function & non-default constructor Message-ID: Hi, Please consider the following variation of the example in the tutorial. The main difference here is that the class that is being wrapped has a non-default destructor. Without a destructor declared in BaseWrap, this gives the error error: base `World' with only non-default constructor in class without a constructor Adding a default constructor to the wrapper class makes the error go away, eg. BaseWrap():Base(0){} I can't find an example of this anywhere. I've looked at the docs, but don't understand what is going on well enough. So, I'm asking here. Is this Ok, and can I use any default constructor for the wrapper class without it making any difference? One other thing. Am I correct in thinking that wrapping the base class in this fashion is necessary if I want to wrap the derived classes? Clarifications appreciated. I'm not subscribed, so please cc me at faheem at email.unc.edu if possible. Thanks. Faheem. ************************************************************************* #include #include #include #include #include #include #include #include #include #include #include #include #include using namespace boost::python; struct Base { int data; Base(int _data):data(_data){} virtual ~Base() {} virtual int f() = 0; }; struct BaseWrap : Base, wrapper { BaseWrap():Base(0){} int f() { return this->get_override("f")(); } }; BOOST_PYTHON_MODULE_INIT(polymorphism2_ext) { class_("Base") .def("f", pure_virtual(&Base::f)) ; } From ericjardim at gmail.com Sat Mar 26 17:33:10 2005 From: ericjardim at gmail.com (Eric Jardim) Date: Sat, 26 Mar 2005 13:33:10 -0300 Subject: [C++-sig] Wrapping a simple class Message-ID: <432ec6c5050326083318cf2ae@mail.gmail.com> Hi, I have read the paper of Boost.Python and the tutorial, and started trying wrapping some handy-made classes to learn how to use Boost.Python with real APIs. My question is simple (I think :) ). Suppose I have this class below: ### a.h ### class A { A* _parent; char* _name; public: A(A* parent=0, const char* name); const char* getName() const; void setName(const char* name); A* getParent() const; }; ### a.cpp ### #include "hello.h" #include A::A(A* parent, const char* name) { _parent = parent; setName(name); } const char* A::getName() const { return _name; } void A::setName(const char* name) { strcpy(_name, name); } A* A::getParent() const { return _parent; } --- The example is simple enough, besides that some functions deals with char* and A* pointers. Reading the turorial and paper I've noticed that the arguments and return values are always ints, bools, doubles and even std::strings, but never custom objects references/pointers. I have tried (trivial) examples before (no pointers) and it worked Ok. But trying this example things do not worked as I expected. I tried exposing this class with something like: #include BOOST_PYTHON_MODULE(hello) { class_("A", init()) .add_property("name", &A::getName, &A::setName) // readwrite property .add_property("parent", &A::getParent) // readonly property ; } Here is my Python script that uses the wrapper: ### hello.py ### import hello a = hello.A(None, 'a') print a, a.name, a.parent b = hello.A(a, 'b') print b, b.name, b.parent --- The expected behaviour is that the "a" object has no parent, so I pass a None (which I suppose that is converted to 0 in C++), and a "b" object has "a" as its parent. The expected output is: >>> import hello >>> a = hello.A(None, 'a') >>> print a, a.name, a.parent a None >>> b = hello.A(a, 'b') >>> print b, b.name, b.parent b --- Thanks in advance. I think if I understand this example things will be much clearer from here on... [Eric Jardim] From ericjardim at gmail.com Sat Mar 26 17:37:20 2005 From: ericjardim at gmail.com (Eric Jardim) Date: Sat, 26 Mar 2005 13:37:20 -0300 Subject: [C++-sig] Re: Wrapping a simple class In-Reply-To: <432ec6c5050326083318cf2ae@mail.gmail.com> References: <432ec6c5050326083318cf2ae@mail.gmail.com> Message-ID: <432ec6c505032608373778d395@mail.gmail.com> Hehe, just a little mistake: The "a.h" and "a.cpp" files are actually "hello.h" and "hello.cpp". Sorry :) [Eric Jardim] From dave at boost-consulting.com Sat Mar 26 21:13:10 2005 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 26 Mar 2005 15:13:10 -0500 Subject: [C++-sig] Re: wrapping class with pure virtual function & non-default constructor References: Message-ID: Faheem Mitha writes: > Hi, > > Please consider the following variation of the example in the > tutorial. The main difference here is that the class that is being > wrapped has a non-default destructor. > > Without a destructor declared in BaseWrap, this gives the error > > error: base `World' with only non-default constructor in class without > a constructor Surely not. Where could the identifier `World' possibly come from in that code? The code compiles for me. I don't think what the error is talking about is really an error in C++, anyway. Are you using -Wall to turn warnings into errors? > Adding a default constructor to the wrapper class makes the error go away, eg. > > BaseWrap():Base(0){} > > I can't find an example of this anywhere. I've looked at the docs, but > don't understand what is going on well enough. So, I'm asking here. > Is this Ok, and can I use any default constructor for the wrapper > class without it making any difference? The answer to your problem, whatever it may be, doesn't really have anything to do with Boost.Python. > One other thing. Am I correct in thinking that wrapping the base class > in this fashion is necessary if I want to wrap the derived classes? No, it's not. > Clarifications appreciated. I'm not subscribed, so please cc me at > faheem at email.unc.edu if possible. > > Thanks. Faheem. > -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Sat Mar 26 21:18:36 2005 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 26 Mar 2005 15:18:36 -0500 Subject: [C++-sig] Re: Wrapping a simple class References: <432ec6c5050326083318cf2ae@mail.gmail.com> Message-ID: Eric Jardim writes: > .add_property("parent", &A::getParent) // readonly property Look into using call policies for this one. http://www.boost.org/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com From clay at idleengineer.net Sat Mar 26 22:26:39 2005 From: clay at idleengineer.net (Clay Culver) Date: Sat, 26 Mar 2005 16:26:39 -0500 Subject: [C++-sig] Python 2.4 timeline? Message-ID: <4245D38F.8040007@idleengineer.net> Is there any timeline or expected date for Python 2.4 to be officially supported? I could compile it myself but I would rather wait until it's supported to upgrade. Thanks, Clay From dholth at fastmail.fm Sun Mar 27 04:00:53 2005 From: dholth at fastmail.fm (Daniel Holth) Date: Sat, 26 Mar 2005 21:00:53 -0500 Subject: [C++-sig] Automatically convert Python objects to constant pointer / const struct s *s? Message-ID: <424613D5.8060105@fastmail.fm> I'm wrapping some functions that look like this: struct data_only { int foo; int bar; int baz[40]; } int use_data(int a, const struct data_only *b) { // ... } I have no trouble converting the struct into Python but I'm unclear how to convert it back. I would like to be able to substitute a dictionary or class with the same properties also, rather than require an instance of that struct. How should I register from-python convertors for this purpose? Thanks, Daniel Holth From rwgk at yahoo.com Sun Mar 27 08:01:46 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Sat, 26 Mar 2005 22:01:46 -0800 (PST) Subject: [C++-sig] Python 2.4 timeline? In-Reply-To: 6667 Message-ID: <20050327060146.4018.qmail@web31508.mail.mud.yahoo.com> --- Clay Culver wrote: > Is there any timeline or expected date for Python 2.4 to be officially > supported? I could compile it myself but I would rather wait until it's > supported to upgrade. Boost.Python works with Python 2.4. This was true even before 2.4 was officially released. I've also tested the latest 2.4.1c2 without running into any problems. Cheers, Ralf __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From nicodemus at esss.com.br Sun Mar 27 17:23:37 2005 From: nicodemus at esss.com.br (Nicodemus) Date: Sun, 27 Mar 2005 13:23:37 -0200 Subject: [C++-sig] Automatically convert Python objects to constant pointer / const struct s *s? In-Reply-To: <424613D5.8060105@fastmail.fm> References: <424613D5.8060105@fastmail.fm> Message-ID: <4246CFF9.9000206@esss.com.br> Hi Daniel, Daniel Holth wrote: > I have no trouble converting the struct into Python but I'm unclear > how to convert it back. I would like to be able to substitute a > dictionary or class with the same properties also, rather than require > an instance of that struct. > > How should I register from-python convertors for this purpose? I think you don't need a from-python convertor to do this. Just use a wrapper function that accepts a boost::python::object as a parameter: int use_data_wrapper(int a, object data_only) { if ( data_only.attr("foo") == 3 ) { data_only.attr("bar") = 4; } // and etc } Hope that helps, Nicodemus. From ericjardim at gmail.com Mon Mar 28 03:29:13 2005 From: ericjardim at gmail.com (Eric Jardim) Date: Sun, 27 Mar 2005 22:29:13 -0300 Subject: [C++-sig] Sub-modules Message-ID: <432ec6c50503271729148fa682@mail.gmail.com> Hi, is it possible to define python sub-modules with boost.python? BOOST_PYTHON_MODULE(out) { BOOST_PYTHON_MODULE(in) { def("f", &f) } } --- >>> import out.in >>> out.in.f() Or something like that? What is the correct way of doing that? I thought that if we could do it separate BOOST_PYTHON_MODULE(out) { } (out.cpp -> out.so) BOOST_PYTHON_MODULE(in) { def("f", &f) } (in.cpp -> in.so) and place them like .../site-packages/ out/ __init__.py out.so in/ __init__.py in.so Anyway, what is the "correct" way of doing that? [Eric Jardim] From ericjardim at gmail.com Mon Mar 28 17:04:28 2005 From: ericjardim at gmail.com (Eric Jardim) Date: Mon, 28 Mar 2005 12:04:28 -0300 Subject: [C++-sig] Constructors (and destrucrtors) wrappers Message-ID: <432ec6c50503280704337b3e2a@mail.gmail.com> Hi, again... There is a case where I have an object constructor that recieves the (int argc, char** argv) parameter from the main function: class QApplication { public: QApplication(int argc, char** argv) {...} ... }; int main(int argc, char** argv) { obj = new QApplication(argc, argv); ... } Is it possible to change the way it is constructed, just passing a list of args (the way of python does) >>> import sys >>> import Qt >>> app = Qt.QApplication(sys.argv) >>> ... I thinked some possibilities: * Creating a free function (or static method) with a factory role. But it could confuse the API... * Extending the class and reimplementing the constructor. I am afraid of this, because I do not know how extended objects will behave in python. Especially if some of them are constructed internally (in c++). The same question is applied to destructors. Any help and insights are welcome :) thanks, [Eric Jardim] From clay at idleengineer.net Mon Mar 28 22:57:43 2005 From: clay at idleengineer.net (Clay Culver) Date: Mon, 28 Mar 2005 15:57:43 -0500 Subject: [C++-sig] Problem after building Boost.Python from source (get_override) Message-ID: <42486FC7.1040601@idleengineer.net> I downloaded the boost source from the sourceforge page and followed these instructions: http://www.boost.org/libs/python/doc/building.html#VisualStudio I'm using Python2.3, Visual Studio 7.1. I opened up the solution (and converted to 7.1) the solution in libs\python\build\VisualStudio. I added the python2.3 include/lib directories and told it to link against python23.lib. Everything built flawlessly. However, when I try to compile my pyste generated wrapper I get an unresolved external symbol to "get_override". The really strange thing though, is that this isn't the only use of get_override. In several of the generated cpp files, get_override is called without any problems, but in some of them it results in these errors: http://www.idleengineer.net/misc/errors.txt Here is one of the files that generates errors: http://www.idleengineer.net/misc/Camera.cpp This is one of the files that does not generate errors, which I can't see anything different: http://www.idleengineer.net/misc/TextureManager.cpp Any ideas what I can do to fix this? Thanks, Clay From mvc at di.fct.unl.pt Tue Mar 29 12:41:55 2005 From: mvc at di.fct.unl.pt (Marco Correia) Date: Tue, 29 Mar 2005 11:41:55 +0100 Subject: [C++-sig] newbie questions... Message-ID: <200503291141.55726.mvc@di.fct.unl.pt> Hi, I just started using boost.python, so please excuse if this is trivial. I have two questions, the first one is related to registering a converter for the std::pair to a python tuple. I've learned that I cannot have bindings for c++ templates, so lets say that T1=T2=int. I'm a little bit lost on how to do this. I thought I had to do something like this: namespace boost { namespace python { template struct to_python_value > { typedef typename add_reference< typename add_const >::type >::type argument_type; static bool convertible() {return true;} PyObject* operator()(argument_type x) const { PyObject* aux1 = to_python_value()(x.first); PyObject* aux2 = to_python_value()(x.second); return Py_BuildValue("(O,O)",aux1,aux2); } }; }; }; and then register this with the 'to_python_converter': to_python_converter, to_python_value > >(); but since the second parameter is supposed to have a convert() method, I guess this is not the way to do it. I could wrap the to_python_value struct in another struct with a convert method, but I have the feeling that I'm complicating things. How do I do this? ---- The next question is about std::set::iterator. I'm trying to come up with a front end in python to a library I've been working on focused on constraint logic programming. A central object in the library is derived from std::set and I would be very happy if my python users could also handle std::set::iterators, for efficiency reasons. I had no problems in converting std::set using pyste, but set::iterator seems more complicated. My first attempt was to try to export only the "std::_Rb_tree_const_iterator". I had to comment a ".def( *self )" line but it compiled and linked with no errors. However, when I import the module in python I get an undefined symbol. Next stop was to try to export all std::_Rb_tree_const_iterator class hierarchy (actually only the std::_Rb_tree_node base class), but still get the undefined symbol. I guess that the .def(*self) is a wrapper for the set::operator*, but this shouldn't be the cause for undefined symbol, or am I wrong? --- I've have read and re-read the tutorial and reference manual of boost.python, and searched the mailing list. I found the boost.python tutorial too basic for these questions and I'm having trouble in learning from the reference manual. Pointers to documentation somewhere between these two are very welcome. Thanks! ps: Please reply me directly since I'm not subscribed. -- Marco Correia From dave at boost-consulting.com Tue Mar 29 20:48:29 2005 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 29 Mar 2005 13:48:29 -0500 Subject: [C++-sig] Re: Constructors (and destrucrtors) wrappers References: <432ec6c50503280704337b3e2a@mail.gmail.com> Message-ID: Eric Jardim writes: > Hi, again... > > There is a case where I have an object constructor that recieves the > (int argc, char** argv) parameter from the main function: > > class QApplication { > public: > QApplication(int argc, char** argv) {...} > ... > }; > > int > main(int argc, char** argv) > { > obj = new QApplication(argc, argv); > ... > } > > Is it possible to change the way it is constructed, just passing a > list of args (the way of python does) You might consider using make_constructor: http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/2065069 shows an example. >>>> import sys >>>> import Qt >>>> app = Qt.QApplication(sys.argv) >>>> ... > > I thinked some possibilities: > * Creating a free function (or static method) with a factory role. > But it could confuse the API... > * Extending the class and reimplementing the constructor. I am > afraid of this, because I do not know how extended objects will behave > in python. Especially if some of them are constructed internally (in > c++). > > The same question is applied to destructors. Hem. Well you can just use: .def("__del__", some_function ) where: void some_function(QApplication& x) { /*whatever*/ } HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com From ericjardim at gmail.com Tue Mar 29 21:31:40 2005 From: ericjardim at gmail.com (Eric Jardim) Date: Tue, 29 Mar 2005 16:31:40 -0300 Subject: [C++-sig] Re: Constructors (and destrucrtors) wrappers In-Reply-To: References: <432ec6c50503280704337b3e2a@mail.gmail.com> Message-ID: <432ec6c50503291131267d8e55@mail.gmail.com> On Tue, 29 Mar 2005 13:48:29 -0500, David Abrahams wrote: > You might consider using make_constructor: > http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/2065069 > shows an example. Funny, why I didn't saw this on the docs? :) Anyway, is that bug, comented on your reply, corrected on the newest version (1.32)? > Hem. Well you can just use: > .def("__del__", some_function ) > where: > void some_function(QApplication& x) { /*whatever*/ } Sure... I tried that before, but I thought that it was too hacky :) I was afraid of overrinding the original destructor or something... I am playing with the Qt3 libraries, just for fun (I know that exists PyQt) and for learning Boost.Python. Soon I will show my homework :) Thanks again, David [Eric Jardim] From dave at boost-consulting.com Tue Mar 29 22:16:21 2005 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 29 Mar 2005 15:16:21 -0500 Subject: [C++-sig] Re: Constructors (and destrucrtors) wrappers References: <432ec6c50503280704337b3e2a@mail.gmail.com> <432ec6c50503291131267d8e55@mail.gmail.com> Message-ID: Eric Jardim writes: > On Tue, 29 Mar 2005 13:48:29 -0500, David Abrahams > wrote: >> You might consider using make_constructor: >> http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/2065069 >> shows an example. > > Funny, why I didn't saw this on the docs? :) > > Anyway, is that bug, comented on your reply, corrected on the newest > version (1.32)? I think so. > >> Hem. Well you can just use: >> .def("__del__", some_function ) >> where: >> void some_function(QApplication& x) { /*whatever*/ } > > Sure... I tried that before, but I thought that it was too hacky :) I > was afraid of overrinding the original destructor or something... Why don't you try it and see what happens? Put a printf in your destructor and see if it gets called. -- Dave Abrahams Boost Consulting www.boost-consulting.com From rwgk at yahoo.com Wed Mar 30 00:49:56 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 29 Mar 2005 14:49:56 -0800 (PST) Subject: [C++-sig] newbie questions... In-Reply-To: 6667 Message-ID: <20050329224956.87144.qmail@web31511.mail.mud.yahoo.com> --- Marco Correia wrote: > the std::pair to a python tuple. I've learned that I cannot have > bindings for c++ templates, so lets say that T1=T2=int. Here you go (tested with g++ 3.2.3): #include #include #include #include namespace { template struct std_pair_to_tuple { static PyObject* convert(std::pair const& p) { return boost::python::incref( boost::python::make_tuple(p.first, p.second).ptr()); } }; template struct std_pair_to_python_converter { std_pair_to_python_converter() { boost::python::to_python_converter< std::pair, std_pair_to_tuple >(); } }; std::pair foo() { std::pair result; result.first = 3; result.second = 5; return result; } } // namespace anonymous BOOST_PYTHON_MODULE(std_pair_example) { using namespace boost::python; std_pair_to_python_converter(); def("foo", foo); } __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From rwgk at yahoo.com Wed Mar 30 01:08:15 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 29 Mar 2005 15:08:15 -0800 (PST) Subject: [C++-sig] newbie questions... In-Reply-To: 6667 Message-ID: <20050329230815.17639.qmail@web31502.mail.mud.yahoo.com> I just checked in a slightly modified version of the code in my previous message; boost/libs/python/example/std_pair.cpp. It would be nice if someone more familiar with bjam could help with the Jamfile. A possible test_std_pair.py: import std_pair_ext assert std_pair_ext.foo() == (3,5) print "OK" --- "Ralf W. Grosse-Kunstleve" wrote: > --- Marco Correia wrote: > > the std::pair to a python tuple. I've learned that I cannot have > > bindings for c++ templates, so lets say that T1=T2=int. > > Here you go (tested with g++ 3.2.3): > > #include ... __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From dave at boost-consulting.com Wed Mar 30 01:46:33 2005 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 29 Mar 2005 18:46:33 -0500 Subject: [C++-sig] Re: newbie questions... References: <20050329224956.87144.qmail@web31511.mail.mud.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > template > struct std_pair_to_python_converter > { > std_pair_to_python_converter() > { > boost::python::to_python_converter< > std::pair, > std_pair_to_tuple >(); > } > }; wouldn't template void std_pair_to_python_converter() { boost::python::to_python_converter< std::pair, std_pair_to_tuple >(); } be so much simpler? -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Wed Mar 30 01:49:27 2005 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 29 Mar 2005 18:49:27 -0500 Subject: [C++-sig] Re: newbie questions... References: <20050329230815.17639.qmail@web31502.mail.mud.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > It would be nice if someone > more familiar with bjam could help with the Jamfile. Just follow the exact pattern used for the other examples in libs/python/example/Jamfile. > A possible > test_std_pair.py: > > import std_pair_ext > assert std_pair_ext.foo() == (3,5) > print "OK" -- Dave Abrahams Boost Consulting www.boost-consulting.com From rwgk at yahoo.com Wed Mar 30 02:10:53 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 29 Mar 2005 16:10:53 -0800 (PST) Subject: [C++-sig] Re: newbie questions... In-Reply-To: 6667 Message-ID: <20050330001054.33560.qmail@web31513.mail.mud.yahoo.com> --- David Abrahams wrote: > wouldn't > > template > void std_pair_to_python_converter() > { > boost::python::to_python_converter< > std::pair, > std_pair_to_tuple >(); > } > > be so much simpler? This is not supported by some older compilers, e.g. gcc 2.96 and possibly older EDG's. __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From dave at boost-consulting.com Wed Mar 30 04:40:42 2005 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 29 Mar 2005 21:40:42 -0500 Subject: [C++-sig] Re: newbie questions... References: <20050330001054.33560.qmail@web31513.mail.mud.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > --- David Abrahams wrote: >> wouldn't >> >> template >> void std_pair_to_python_converter() >> { >> boost::python::to_python_converter< >> std::pair, >> std_pair_to_tuple >(); >> } >> >> be so much simpler? > > This is not supported by some older compilers, e.g. gcc 2.96 and possibly older > EDG's. yeesh. :( -- Dave Abrahams Boost Consulting www.boost-consulting.com From mvc at di.fct.unl.pt Wed Mar 30 15:49:18 2005 From: mvc at di.fct.unl.pt (Marco Correia) Date: Wed, 30 Mar 2005 14:49:18 +0100 Subject: [C++-sig] Re: newbie questions... In-Reply-To: <200503291141.55726.mvc@di.fct.unl.pt> References: <200503291141.55726.mvc@di.fct.unl.pt> Message-ID: <200503301449.18234.mvc@di.fct.unl.pt> Hi, Thanks a lot for the replies. I was not subscribed (I have been following this thread on the mailing list archives), and therefore I'm not sure if this mail will be filed in the correct thread (I'm hoping that keeping the same subject line will do it). Ok, so here are my questions: - Will this solution work with a user defined type UserT, i.e. will it allow python users to handle pair ? - If not, then why can't we just have a single 'convert_to_python' template which we would then specialize for user defined types, and use it in the convert function as I did in my previous post? - Where is the documentation for boost::python::incref ? I can't find it in the reference manual. thanks! -- Marco Correia