From david at hotjobs2000.com Tue Nov 9 03:50:06 1999 From: david at hotjobs2000.com (David Winsen) Date: Mon, 8 Nov 1999 18:50:06 -0800 Subject: [C++-SIG] WEB DATABASE PROGRAMMER POSITION AVAILABLE Message-ID: <000801bf2a5d$2b8f4d00$2a2565d8@pacbell.net> WEB DATABASE PROGRAMMER POSITION AVAILABLE URGENT MESSAGE! From: David Winsen - Senior Consultant - High Technology Executive Search We have an out-dated copy of your resume in our database or have viewed your credentials on the internet. HTES is an established national Executive Search and Consulting Firm who has been serving the High Tech Industries for over 25 years. We have been confidentially retained by a Los Angeles, Ca. based Adult Internet Fulfillment/Billing Company. Salary is $50k-$100k DOE. We are confidentially pre-screening top candidates for the following position: Web Database Programmer Description Candidates will need to be extremely detail oriented and have a solid work ethic. Will be developing cutting edge software and e-commerce applications. They are an established and ever growing Internet Fulfillment/Billing Company. They offer a casual & unique work environment unlike any other, full benefits, & room for growth and advancement. Requirements Candidates will need experience in Perl, Python, PHP, Javascript, UNIX, Linux or FreeBSD, MySQL a plus. BS Computer Science or equivalent. At least 3 years of Web experience is a plus. If you are interested, please E-mail me in MS Word 95-98 a recent copy of your resume and a cover letter with your specific information, including your recent compensation package to Position-for: Web Database Programmer My personal E-mail is david at hotjobs2000.com or fax your resume to (310) 855-0840. If you have any questions about the position(s), please call me at (310) 855-0406 and I will discuss them in detail. We also have developed an interactive Website that you can view over 6000 national openings www.hotjobs2000.com. This system is effective, easy to use and new positions are posted daily. We encourage you to use it and nominate yourself for other positions you feel you are qualified for. We are looking forward to working with you now and in the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ephi at adital.com Sun Nov 14 21:04:59 1999 From: ephi at adital.com (Ephi Dror) Date: Sun, 14 Nov 1999 12:04:59 -0800 Subject: [C++-SIG] Beginer questions Message-ID: <002c01bf2edb$887a5fa0$b7e856ce@london> Hi All, I am a beginner in Python and kind of confused on the subject of combining C++ and Python. I understand that there are 2 ways of interaction. We in our project are only interesting in the case that you call C++ classes and functions from Python, We would like to use C++ classes that are already written in C++ from Python script. We successfully built a shared library with C api, import it and call the function from Python, but when it comes to calling C++, we are completely in the dark and would appreciate any help in that area. Once we understand the subject we would be glad to help other to come up to speed as well. Here is our questions: 1. At this point we are trying to wrap the C++ class as C, but our problem is, how do we pass a pointer from Python to C++ so we can keep the pointer to the class. 2. Is there any easer way to call the functions of C++ classes from python instead of wrapping them with C functions. 3. We recently came across CObject Python object. is it the solution to pass pointer to C function from Python. Is there any example available on this? 4. About Swig. Is swig the best solution for calling C++ from Python. Thanks a lot in advanced for any information which can shade some light on this subject. Ephi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ians at amc.com Sun Nov 14 23:45:05 1999 From: ians at amc.com (Ian Searle) Date: Sun, 14 Nov 1999 14:45:05 -0800 Subject: [C++-SIG] Beginer questions References: <002c01bf2edb$887a5fa0$b7e856ce@london> Message-ID: <382F3B71.8F33C6EE@amc.com> I just spent the last few days developing a C++ extension to Python. While I am by no means an expert, I do have some relevant information floating about in my short term memory. The extension we developed was much like what you describe. A rather complex C++ class (set of classes) is already in the form of a library, and we want to be able to instantiate these object(s) from Python, call their methods, and get at their data, etc... One of the programmers in my group first attempted this using the LLNL CXX package to develop the extension. This resulted in lots of trouble for us, which has yet to be resolved. Not because the CXX package isn't good. The problem may be that it is too good, or more precisely, uses C++ constructs that are too much for g++ (GCC-2.95.2). In this particular instance, g++ (Solaris) has a nasty bug that does not allow code built with it to catch exceptions. Instead, the exceptions get thrown all the way to the default exception handler which causes a core dump. We have absolutely no problems when we build the extension on Windows with VC++. Solaris, with g++ is another story altogether though. So, as a means to explore alternatives, I wrote the C++ extension by hand. It turned out to fairly simple, and efficient (at least so far, I am only part way through my unit tests). To do this, I just developed a type extension for Python, almost exactly as described in the book: "Internet Programming with Python" (see the bstreammodule example). Adding a new type to Python gives you the opportunity to stash a pointer to your C++ object in the object structure. Important things to note: 1) the init function must be declared extern "C" so that it can be runtime linked with Python. The rest of the functions don't matter, as they are declared static, and they show up in the method tables anyways. 2) No global objects as we are linking against a C compiled Python. The C++ library the we wrote an extension for makes _heavy_ use of C++ STL containers. Getting select data out of the containers and into Python tuples, lists, and dictionaries is fairly simple. The hard part (assuming you are familiar with your own library) is learning the expectations of Python extensions. I found the book, and the standard Python documentation to be just fine. When we used the LLNL CXX extension, our contribution was about 500 lines of code. The "plain" extension is also about 500 lines of code. The main difference is in writing the plain extension I avoided use of C++ exceptions, and other C++ features that I know are not very portable (like new iostreams, but don't get me started...) I hope this helps. Cheers, -Ian Searle Ephi Dror wrote: > Hi All, I am a beginner in Python and kind of confused on the subject > of combining C++ and Python. I understand that there are 2 ways of > interaction. We in our project are only interesting in the case that > you call C++ classes and functions from Python, We would like to use > C++ classes that are already written in C++ from Python script. We > successfully built a shared library with C api, import it and call the > function from Python, but when it comes to calling C++, we are > completely in the dark and would appreciate any help in that area. > Once we understand the subject we would be glad to help other to come > up to speed as well. Here is our questions:1. At this point we are > trying to wrap the C++ class as C, but our problem is, how do we pass > a pointer from Python to C++ so we can keep the pointer to the > class.2. Is there any easer way to call the functions of C++ classes > from python instead of wrapping them with C functions.3. We recently > came across CObject Python object. is it the solution to pass pointer > to C function from Python. Is there any example available on this?4. > About Swig. Is swig the best solution for calling C++ from > Python. Thanks a lot in advanced for any information which can shade > some light on this subject. Ephi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dubois1 at llnl.gov Mon Nov 15 03:54:12 1999 From: dubois1 at llnl.gov (Paul F. Dubois) Date: Sun, 14 Nov 1999 18:54:12 -0800 Subject: [C++-SIG] Beginer questions References: <002c01bf2edb$887a5fa0$b7e856ce@london> <382F3B71.8F33C6EE@amc.com> Message-ID: <000f01bf2f14$b2a878a0$3c810b18@plstn1.sfba.home.com> This reminds me to call attention of the C++ SIG to the article in the July/Aug 1999 C++ report that explains that pointers to C functions and pointers to C++ functions are no longer type compatible. This has serious implications for extending Python with C++, in that Python's tables expect a C function. Up to now it has been possible to just cast whatever to PyCFunction and move on; evidently some compilers will now start to object to that if the function in question is a C++ one. I haven't had time to look at this to see if I have a decent work-around. -------------- next part -------------- An HTML attachment was scrubbed... URL: From JWight at bigfoot.com Mon Nov 15 04:46:23 1999 From: JWight at bigfoot.com (Jonathan Wight) Date: Sun, 14 Nov 1999 21:46:23 -0600 Subject: [C++-SIG] Beginer questions In-Reply-To: <000f01bf2f14$b2a878a0$3c810b18@plstn1.sfba.home.com> Message-ID: on 11/14/99 20:54, Paul F. Dubois at dubois1 at llnl.gov wrote: > This reminds me to call attention of the C++ SIG to the article in the > July/Aug 1999 C++ report that explains that pointers to C functions and > pointers to C++ functions are no longer type compatible. This has serious > implications for extending Python with C++, in that Python's tables expect a C > function. Up to now it has been possible to just cast whatever to PyCFunction > and move on; evidently some compilers will now start to object to that if the > function in question is a C++ one. I haven't had time to look at this to see > if I have a decent work-around. If it is a static function couldn't you just declare it as " extern "C" "??? I know that works fine for various callbacks in the OS. Jon. From ians at amc.com Mon Nov 15 04:59:12 1999 From: ians at amc.com (Ian R. Searle) Date: Sun, 14 Nov 1999 19:59:12 -0800 Subject: [C++-SIG] Beginer questions References: Message-ID: <382F8510.F9B0570F@amc.com> Jonathan Wight wrote: > > on 11/14/99 20:54, Paul F. Dubois at dubois1 at llnl.gov wrote: > > > This reminds me to call attention of the C++ SIG to the article in the > > July/Aug 1999 C++ report that explains that pointers to C functions and > > pointers to C++ functions are no longer type compatible. This has serious > > implications for extending Python with C++, in that Python's tables expect a C > > function. Up to now it has been possible to just cast whatever to PyCFunction > > and move on; evidently some compilers will now start to object to that if the > > function in question is a C++ one. I haven't had time to look at this to see > > if I have a decent work-around. > > If it is a static function couldn't you just declare it as " extern "C" "??? > I know that works fine for various callbacks in the OS. > > Jon. Sorry for my ignorance. Is the C++ report something put out by the standard committee ? Is this something new to the standard, or has this "feature" been there for a while ? Thanks, -Ian From kallmann at lig.di.epfl.ch Mon Nov 15 11:06:45 1999 From: kallmann at lig.di.epfl.ch (Marcelo Kallmann) Date: Mon, 15 Nov 1999 11:06:45 +0100 Subject: [C++-SIG] Controlling python execution from C Message-ID: <382FDB35.B8F8397C@lig.di.epfl.ch> Hello, Looking at the manuals, I saw that the function Py_NewInterpreter(), "simulates" the creation of a new thread, so that different scripts would be interpreted "pratically" in paralell by interpreting some bytecodes of each one from time to time. There is even a method to say how many bytecodes to interpret in one script (default=10) before changing to interpret the next script. I tryed to test this feature from C calls, by playing with thread states, interpreter states, run_string, etc, but with no success... What I would like to do is to have n scripts ( char *script[n]; ), and be able to run them in the same application loop, having something like : while ( true ) { for ( int i=0; i Message-ID: On Mon, 15 Nov 1999, Marcelo Kallmann wrote: >... > while ( true ) > { for ( int i=0; i { restore_python_thread_state ( i ); // would call python functions to > restore internal states, etc. > run_some_bytecodes_of_python_script ( script[i] ); // would not block > my loop, would not run all the script ! > } > .... > } > > So, first of all, my question is : Is this possible to do ? Nope. Sorry. The Python interpreter runs to completion. It will not "unwind" and return to your loop. It uses *real* threads, and blocks on one to cause a context switch to another ready-thread. Well... more specifically, one thread grabs the global lock. Periodically, it releases it and re-acquires it. In that short time-frame when it doesn't hold the lock, another thread can wake up, grab it, and begin execution for a while. Cheers, -g -- Greg Stein, http://www.lyra.org/ From beazley at cs.uchicago.edu Mon Nov 15 13:40:30 1999 From: beazley at cs.uchicago.edu (David Beazley) Date: Mon, 15 Nov 1999 06:40:30 -0600 (CST) Subject: [C++-SIG] Beginer questions References: <002c01bf2edb$887a5fa0$b7e856ce@london> <382F3B71.8F33C6EE@amc.com> <000f01bf2f14$b2a878a0$3c810b18@plstn1.sfba.home.com> Message-ID: <199911151240.GAA02159@gargoyle.cs.uchicago.edu> Paul F. Dubois writes: > > This reminds me to call attention of the C++ SIG to the article in the = > July/Aug 1999 C++ report that explains that pointers to C functions and = > pointers to C++ functions are no longer type compatible. This has = > serious implications for extending Python with C++, in that Python's = > tables expect a C function. Up to now it has been possible to just cast = > whatever to PyCFunction and move on; evidently some compilers will now = > start to object to that if the function in question is a C++ one. I = > haven't had time to look at this to see if I have a decent work-around. > I ran into this problem with SWIG when I upgraded to a new C++ compiler. To get around it, I just placed all of the wrapper code inside an extern "C" block. I'm not sure if this is an ideal solution and I have no idea what it means for CXX. It seemed to work for SWIG however. Cheers, Dave From ians at amc.com Mon Nov 15 15:18:02 1999 From: ians at amc.com (Ian Searle) Date: Mon, 15 Nov 1999 06:18:02 -0800 Subject: [C++-SIG] Beginer questions References: <002c01bf2edb$887a5fa0$b7e856ce@london> <382F3B71.8F33C6EE@amc.com> <000f01bf2f14$b2a878a0$3c810b18@plstn1.sfba.home.com> <199911151240.GAA02159@gargoyle.cs.uchicago.edu> Message-ID: <3830161A.B9667649@amc.com> You can place all of the C++ function declarations, the ones that appear in the method tables in an extern "C" wrapper too. But, that has the very ugly side effect of exposing your entire interface to the world. -Ian David Beazley wrote: > Paul F. Dubois writes: > > > > This reminds me to call attention of the C++ SIG to the article in the = > > July/Aug 1999 C++ report that explains that pointers to C functions and = > > pointers to C++ functions are no longer type compatible. This has = > > serious implications for extending Python with C++, in that Python's = > > tables expect a C function. Up to now it has been possible to just cast = > > whatever to PyCFunction and move on; evidently some compilers will now = > > start to object to that if the function in question is a C++ one. I = > > haven't had time to look at this to see if I have a decent work-around. > > > > I ran into this problem with SWIG when I upgraded to a new C++ > compiler. To get around it, I just placed all of the wrapper code > inside an extern "C" block. I'm not sure if this is an ideal > solution and I have no idea what it means for CXX. It seemed to work > for SWIG however. > > Cheers, > > Dave From furnish at actel.com Mon Nov 15 18:15:38 1999 From: furnish at actel.com (Geoffrey Furnish) Date: Mon, 15 Nov 1999 09:15:38 -0800 (PST) Subject: [C++-SIG] Beginer questions In-Reply-To: <002c01bf2edb$887a5fa0$b7e856ce@london> References: <002c01bf2edb$887a5fa0$b7e856ce@london> Message-ID: <14384.16314.790157.773483@gargle.gargle.HOWL> Ian already mentioned the possibility of writing your own type extension. Building on that notion... Ephi Dror writes: > 1. At this point we are trying to wrap the C++ class as C, but our > problem is, how do we pass a pointer from Python to C++ so we can > keep the pointer to the class. You can arrange that the methods of your type extension downcast the "self" pointer passed to them, to make it a pointer to your object, and then invoke member functions on it. Something like this: static PyObject * myext_meth1( PyObject *self, PyObject *args ) { MyObject *myo = static_cast(self); return myo->meth1( args ); } > 2. Is there any easer way to call the functions of C++ classes from > python instead of wrapping them with C functions. You can write scripts to automate the production of wrappers like that shown above. Or you can use CXX, as Ian mentioned. Some formalization of the techniques exhibited in CXX is what several of us regard as the end goal deliverable for this SIG. But it is proving challenging to do this, given the constraints of personal time and effort, as well as standards conformance. -- Geoffrey Furnish Actel Corporation furnish at actel.com Senior Staff Engineer 955 East Arques Ave voice: 408-522-7528 Placement & Routing Sunnyvale, CA 94086-4533 fax: 408-328-2303 "... because only those who write the code truly control the project." -- Jamie Zawinski From furnish at actel.com Mon Nov 15 18:31:30 1999 From: furnish at actel.com (Geoffrey Furnish) Date: Mon, 15 Nov 1999 09:31:30 -0800 (PST) Subject: [C++-SIG] Beginer questions In-Reply-To: <382F3B71.8F33C6EE@amc.com> References: <002c01bf2edb$887a5fa0$b7e856ce@london> <382F3B71.8F33C6EE@amc.com> Message-ID: <14384.17266.543562.234730@gargle.gargle.HOWL> Ian Searle writes: > One of the programmers in my group first attempted this using the > LLNL CXX package to develop the extension. This resulted in lots > of trouble for us, which has yet to be resolved. Not because the > CXX package isn't good. The problem may be that it is too good, or > more precisely, uses C++ constructs that are too much for g++ > (GCC-2.95.2). In this particular instance, g++ (Solaris) has a > nasty bug that does not allow code built with it to catch > exceptions. Instead, the exceptions get thrown all the way to the > default exception handler which causes a core dump. We have > absolutely no problems when we build the extension on Windows with > VC++. Solaris, with g++ is another story altogether though. I have also been unable to use GCC-2.95 for my other code projects, due to other apparent code gen bugs and miscelaneous other problems. GCC 2.95 is a landmark event--a reason for great excitement--but it isn't prime-time yet, I'm afraid. > So, as a means to explore alternatives, I wrote the C++ extension > by hand. It turned out to fairly simple, and efficient (at least > so far, I am only part way through my unit tests). To do this, I > just developed a type extension for Python, almost exactly as > described in the book: "Internet Programming with Python" (see the > bstreammodule example). Adding a new type to Python gives you the > opportunity to stash a pointer to your C++ object in the object > structure. Important things to note: Right, this is a very feasible approach. The goal of CXX is to make this as easy as declaring a derived object. But one can certainly do it oneself. > 2) No global objects as we are linking against a C compiled Python. There is a patch posted on the C++ SIG website, which modifies the configure script for Python to allow you to get your main linked with C++, which ensoures that global ctors get run correctly. If you use that, you don't need rule 2) above. > The C++ library the we wrote an extension for makes _heavy_ use of C++ > STL containers. Note that this is in potential contradiction with your rule 2) above. I'm sure you know that iostreams depends on global ctors, so your rule 2) means that cout is out. But also, some STL implementations make use of static global objects, and I don't see anything to imply that such an implementation is specifically nonconformant. So I would be worried that your current prescription is working due to fortuitous happenstance, depending on unspecified behavior of your current tool chain(s). > Getting select data out of the containers and into > Python tuples, lists, and dictionaries is fairly simple. The hard part > (assuming you are familiar with your own library) is learning the > expectations of Python extensions. I found the book, and the standard > Python documentation to be just fine. CXX is also supposed to make this issue of ownership management trivial. > When we used the LLNL CXX extension, our contribution was about 500 > lines of code. The "plain" extension is also about 500 lines of code. > The main difference is in writing the plain extension I avoided use of > C++ exceptions, and other C++ features that I know are not very portable > (like new iostreams, but don't get me started...) Frustrating, isn't it? I would add though, that its been more than 3 years since I have personally experienced a vendor C++ compiler whose exception mechanism didn't work. Outside of GCC, the rough points in C++ these days seem to lie in the areas of partial specialization, namespace resolution lookup rules, and associated arcana. GCC is generally conformant in almost all areas, but just has some issues with uneven implementation quality. Best regards, -- Geoffrey Furnish Actel Corporation furnish at actel.com Senior Staff Engineer 955 East Arques Ave voice: 408-522-7528 Placement & Routing Sunnyvale, CA 94086-4533 fax: 408-328-2303 "... because only those who write the code truly control the project." -- Jamie Zawinski From furnish at actel.com Mon Nov 15 18:34:02 1999 From: furnish at actel.com (Geoffrey Furnish) Date: Mon, 15 Nov 1999 09:34:02 -0800 (PST) Subject: [C++-SIG] Beginer questions In-Reply-To: References: <000f01bf2f14$b2a878a0$3c810b18@plstn1.sfba.home.com> Message-ID: <14384.17418.183972.451503@gargle.gargle.HOWL> Jonathan Wight writes: > on 11/14/99 20:54, Paul F. Dubois at dubois1 at llnl.gov wrote: > > > This reminds me to call attention of the C++ SIG to the article > > in the July/Aug 1999 C++ report that explains that pointers to C > > functions and pointers to C++ functions are no longer type > > compatible. This has serious implications for extending Python > > with C++, in that Python's tables expect a C function. Up to now > > it has been possible to just cast whatever to PyCFunction and > > move on; evidently some compilers will now start to object to > > that if the function in question is a C++ one. I haven't had time > > to look at this to see if I have a decent work-around. > > If it is a static function couldn't you just declare it as " extern > "C" "??? I know that works fine for various callbacks in the OS. You can declare a non-member function in C++ to have extern "C" linkage, whether it is static or not. Of course you lose linkage safety if you do this, but you can do it. -- Geoffrey Furnish Actel Corporation furnish at actel.com Senior Staff Engineer 955 East Arques Ave voice: 408-522-7528 Placement & Routing Sunnyvale, CA 94086-4533 fax: 408-328-2303 "... because only those who write the code truly control the project." -- Jamie Zawinski From furnish at actel.com Mon Nov 15 18:42:28 1999 From: furnish at actel.com (Geoffrey Furnish) Date: Mon, 15 Nov 1999 09:42:28 -0800 (PST) Subject: [C++-SIG] Beginer questions In-Reply-To: <382F8510.F9B0570F@amc.com> References: <382F8510.F9B0570F@amc.com> Message-ID: <14384.17924.27963.437490@gargle.gargle.HOWL> Ian R. Searle writes: > Sorry for my ignorance. Is the C++ report something put out by the > standard committee ? The C++ Report is a C++ trade rag that has been in circulation for about a decade, give or take. It is not affiliated with the committee, but it has over the yeards, reported on the actions of the committee. An excellent source for C++ trade lore. > Is this something new to the standard, or has this "feature" been > there for a while ? As far as I know, global C++ functions (non member functions) that are not explicitly declared to be extern "C", have never been guaranteed to be compatible with C functions. The impact of this on the Python/C++ integration work, imo, is that we must be able to build extension object method tables without casting to PyCFunction. This probably means implicitly-instantiable per-class templated trampoline machinery. Note, I had decided to not do the "cast to PyCFunction" thing on my first reading of the bstreammodule code. The CPython implementation uses PyCFunctions for two different function signatures--those with keyword args and those without. Clearly you can only get away with shenanigans like that in the unsafe world of C. Any C++ binding will have to regard such function signatures as being of different function pointer types, and strictly conforming C++ compilers will not let you blithely cast between them. -- Geoffrey Furnish Actel Corporation furnish at actel.com Senior Staff Engineer 955 East Arques Ave voice: 408-522-7528 Placement & Routing Sunnyvale, CA 94086-4533 fax: 408-328-2303 "... because only those who write the code truly control the project." -- Jamie Zawinski From dgrisby at uk.research.att.com Mon Nov 15 18:45:06 1999 From: dgrisby at uk.research.att.com (Duncan Grisby) Date: Mon, 15 Nov 1999 17:45:06 +0000 Subject: [C++-SIG] Beginer questions In-Reply-To: Your message of "Mon, 15 Nov 1999 09:31:30 PST." <14384.17266.543562.234730@gargle.gargle.HOWL> Message-ID: <199911151745.RAA05691@pineapple.cam-orl.co.uk> On Monday 15 November, Geoffrey Furnish wrote: [...] > > 2) No global objects as we are linking against a C compiled Python. > > There is a patch posted on the C++ SIG website, which modifies the > configure script for Python to allow you to get your main linked with > C++, which ensoures that global ctors get run correctly. If you use > that, you don't need rule 2) above. I'm intrigued by the assertion that you can't use global objects when the Python executable is compiled with C. For which platforms is it true? I've successfully used global C++ objects with constructors on Linux, Solaris and Windows NT, without compiling Python itself with C++. I've done this while providing Python bindings for omniORB. My Python extension module does not have any global objects itself, but it is (dynamically) linked with the main omniORB library which does. Maybe that's why it works? Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From phil at geog.ubc.ca Mon Nov 15 19:06:47 1999 From: phil at geog.ubc.ca (Phil Austin) Date: Mon, 15 Nov 1999 10:06:47 -0800 (PST) Subject: [C++-SIG] Beginer questions In-Reply-To: <199911151745.RAA05691@pineapple.cam-orl.co.uk> References: <14384.17266.543562.234730@gargle.gargle.HOWL> <199911151745.RAA05691@pineapple.cam-orl.co.uk> Message-ID: <14384.19383.759894.140565@brant.geog.ubc.ca> Duncan Grisby writes: > On Monday 15 November, Geoffrey Furnish wrote: > > [...] > > > > 2) No global objects as we are linking against a C compiled Python. > > > > There is a patch posted on the C++ SIG website, which modifies the > > configure script for Python to allow you to get your main linked with > > C++, which ensoures that global ctors get run correctly. If you use > > that, you don't need rule 2) above. > > I'm intrigued by the assertion that you can't use global objects when > the Python executable is compiled with C. For which platforms is it > true? I've successfully used global C++ objects with constructors on > Linux, Solaris and Windows NT, without compiling Python itself with > C++. > 1. ((off topic) If you eat lunch with anyone who's responsible for http://www.uk.research.att.com/vnc, pass on my thanks for a great piece of software) 2. I've been assuming that all implementations that use ELF-based shared libraries initialize global objects correctly. This was mentioned in an article in Computing in Science and Engineering: @Article{Gray99Shadow, author = {M. C. Gray and R. M. Roberts and T. M. Evans}, title = {Shadow-object interface between Fortran95 and C++}, journal = {Comp. in Sci. and Engineer.}, year = 1999, volume = 1, number = 2, pages = {63-70}, annote = {http://computer.org} } They support their statment with a footnote to the Linker and Libraries Guide, Solaris 2.6 Software Developer Collection vol 1., http:://docs.sun.com. Phil From furnish at actel.com Mon Nov 15 20:09:59 1999 From: furnish at actel.com (Geoffrey Furnish) Date: Mon, 15 Nov 1999 11:09:59 -0800 (PST) Subject: [C++-SIG] Beginer questions In-Reply-To: <199911151745.RAA05691@pineapple.cam-orl.co.uk> References: <14384.17266.543562.234730@gargle.gargle.HOWL> <199911151745.RAA05691@pineapple.cam-orl.co.uk> Message-ID: <14384.23175.984090.286208@gargle.gargle.HOWL> Duncan Grisby writes: > > > 2) No global objects as we are linking against a C compiled Python. > > > > There is a patch posted on the C++ SIG website, which modifies the > > configure script for Python to allow you to get your main linked with > > C++, which ensoures that global ctors get run correctly. If you use > > that, you don't need rule 2) above. > > I'm intrigued by the assertion that you can't use global objects when > the Python executable is compiled with C. For which platforms is it > true? C does not have global ctors, so if you build a C program, you can't expect C++ global ctors to get run, unless you have detailed, platform-specific knowledge to the contrary. Exactly how global ctors get run in C++ is platform specific. The standard just mandates that global ctors get run before main() is called. Exactly how it happens depends on the compiler. I think Myers explains this in his first book at some length. > I've successfully used global C++ objects with constructors on > Linux, Solaris and Windows NT, without compiling Python itself with > C++. You were lucky. That's the linker being nice to you. > I've done this while providing Python bindings for omniORB. My Python > extension module does not have any global objects itself, but it is > (dynamically) linked with the main omniORB library which does. Maybe > that's why it works? Many dynamic linkers do the global ctor thing correctly. BTW, this is not just ELF as was mentioned in a sperate post. In general, a good dynamic linker ought to understand the notion that a dynloaded library might need initialization or finalization code to be run. But that's part of the ABI for a computing platform, not the C++ language definition. On the other hand, if you build a Python with a C++ extension module statically linked in, it will quite likely fail, unless the C++ compiler compiles main(), and drives the link. In this case, the issue is not just getting the special initialization and finalization code to be draped around main(), but also because of the need to perform implicit instantiations. Again, one can luck out. Some systems have linkers that "do it right" irrespective of what the compilers did. And some compilers use gross bloating template instantiation techniques that ensure simplistic linkage models will "work", but do so at the expense of bloating executable size, and consequent reductions in I-cache locality. But if you want it to work because you did it right, and not merely because you were lucky, then you need to compile main() with C++, and let C++ run the link. -- Geoffrey Furnish Actel Corporation furnish at actel.com Senior Staff Engineer 955 East Arques Ave voice: 408-522-7528 Placement & Routing Sunnyvale, CA 94086-4533 fax: 408-328-2303 "... because only those who write the code truly control the project." -- Jamie Zawinski From phil at geog.ubc.ca Mon Nov 15 20:43:46 1999 From: phil at geog.ubc.ca (Phil Austin) Date: Mon, 15 Nov 1999 11:43:46 -0800 (PST) Subject: C++ patch (was: [C++-SIG] Beginer questions) In-Reply-To: <14384.23175.984090.286208@gargle.gargle.HOWL> References: <14384.17266.543562.234730@gargle.gargle.HOWL> <199911151745.RAA05691@pineapple.cam-orl.co.uk> <14384.23175.984090.286208@gargle.gargle.HOWL> Message-ID: <14384.25202.779821.955823@brant.geog.ubc.ca> Geoffrey Furnish writes: > > But if you want it to work because you did it right, and not merely > because you were lucky, then you need to compile main() with C++, and > let C++ run the link. > > -- Further to that goal, patch.geoff is failing for me on Makefile.pre.in and configure.in. To get it to work I had to cp Modules/Makefile.pre.in to Python-1.5.2 and replace the line AC_REVISION($Revision: 1.103 $) in configure.in with AC_REVISION($Revision: 1.1 $) Regards, Phil From kallmann at lig.di.epfl.ch Wed Nov 17 13:56:13 1999 From: kallmann at lig.di.epfl.ch (Marcelo Kallmann) Date: Wed, 17 Nov 1999 13:56:13 +0100 Subject: [C++-SIG] Re: [Thread-SIG] Controlling python execution from C References: Message-ID: <3832A5ED.262E9D22@lig.di.epfl.ch> > The Python interpreter runs to completion. It will not "unwind" and return > to your loop. > > It uses *real* threads, and blocks on one to cause a context switch to > another ready-thread. > > Well... more specifically, one thread grabs the global lock. Periodically, > it releases it and re-acquires it. In that short time-frame when it > doesn't hold the lock, another thread can wake up, grab it, and begin > execution for a while. Thank you for the info. So, I would be able to do something like : char *scripts[N]; // my n scripts for ( i=0; i Hi All, We are exploring the possibility of using Python with conjunction with C++. I recently posted the "Beginner Question" and would like to thank all of you for the great discussion and support we have received. We have managed to make great progress however we run into couple of very strange problems which I would like to bring up here and share them with the group. Any help in solving these issues will be highly appreciated and beneficiary for all. We also think that the attached example could be good starting point for beginners to understand the concept of calling C++ objects from Python. The example contains a simple C++ class with two data members and we have a simple python script which uses the class. The two problems are: 1. The value of the first data member in the class is ok in the constructor, but in all the rest of the member functions it added 2 to the first data member. 2. When we call the destructor, It is executing the destructor, but we get "Segmentation fault" after it finished to execute the python script that calls the functions that call c++ functions. Here is general information on: 1. We use Linux version 6.1 from redhat. 2. We use gcc version egcs-2.91.66 from redhat. 3. we use Python version 1.5.2 compiled with same gcc from redhat. 4. The class files are: spam.cpp and spam.h . 5. The files that include the c functions that wrap the class functions are : c_spam.cpp and c_spam.h . 6. The file that has the module extension is : ext_spam.cpp. 7. The file that includes the Python script that call the c++ is run. We suspect that the problems might be one or combination of the following issues: 2. Makefile bug (C++ flags and/or shared lib flags are missing). 3. Incompatibility between the way python was built and the version of GCC/C++ we use for the example. Thanks a lot in advance for your cooperation , Cheers, Ephi. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: spam.tgz Type: application/x-compressed Size: 1299 bytes Desc: not available URL: From mhammond at skippinet.com.au Tue Nov 23 08:34:46 1999 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 23 Nov 1999 18:34:46 +1100 Subject: [C++-SIG] Python calling C++ issues In-Reply-To: <00bc01bf357e$f51c7ea0$b7e856ce@london> Message-ID: <002e01bf3585$37fa5b60$0501a8c0@bobcat> The problem is that Python thinks it is giving you an "Object *", but you are passing a "Spam *". For the same object, an "Object *" is off by the size of the virtual function pointer - an "Object *" doesnt have a vfptr, but a "Spam *" does. Change your code to: static PyObject* ext_Spam_Display(PyObject* self, PyObject* args) { Object *obSpam; if (!PyArg_ParseTuple(args, "O", &obSpam)) return NULL; Spam* spam = (Spam *)obSpam; Spam_Display(spam); return Py_BuildValue(""); } Check in the debugger - the "Object *" and "Spam *" will be different, even though they are the same object! Mark. -----Original Message----- From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On Behalf Of Ephi Dror Sent: Tuesday, 23 November 1999 5:50 To: c++-sig at python.org Subject: [C++-SIG] Python calling C++ issues Hi All, We are exploring the possibility of using Python with conjunction with C++. I recently posted the "Beginner Question" and would like to thank all of you for the great discussion and support we have received. We have managed to make great progress however we run into couple of very strange problems which I would like to bring up here and share them with the group. Any help in solving these issues will be highly appreciated and beneficiary for all. We also think that the attached example could be good starting point for beginners to understand the concept of calling C++ objects from Python. The example contains a simple C++ class with two data members and we have a simple python script which uses the class. The two problems are: 1. The value of the first data member in the class is ok in the constructor, but in all the rest of the member functions it added 2 to the first data member. 2. When we call the destructor, It is executing the destructor, but we get "Segmentation fault" after it finished to execute the python script that calls the functions that call c++ functions. Here is general information on: 1. We use Linux version 6.1 from redhat. 2. We use gcc version egcs-2.91.66 from redhat. 3. we use Python version 1.5.2 compiled with same gcc from redhat. 4. The class files are: spam.cpp and spam.h . 5. The files that include the c functions that wrap the class functions are : c_spam.cpp and c_spam.h . 6. The file that has the module extension is : ext_spam.cpp. 7. The file that includes the Python script that call the c++ is run. We suspect that the problems might be one or combination of the following issues: 2. Makefile bug (C++ flags and/or shared lib flags are missing). 3. Incompatibility between the way python was built and the version of GCC/C++ we use for the example. Thanks a lot in advance for your cooperation , Cheers, Ephi. From ephi at adital.com Wed Nov 24 09:28:44 1999 From: ephi at adital.com (Ephi Dror) Date: Wed, 24 Nov 1999 00:28:44 -0800 Subject: [C++-SIG] Python calling C++ issues References: <002e01bf3585$37fa5b60$0501a8c0@bobcat> Message-ID: <003401bf3655$ec6dc480$b7e856ce@london> Hi Mark, Thanks a lot for your great help. Unfortunately, we don't seems to understand what do you mean by "Object". Is it something we need to define or is it already defined in a h file that we forgot to include. We use Linux/gcc environment. Also, in our sample, we did not use virtual function Below, for all of us we are using the WEB to look at the SIG C++ posting , please find the project files. Thanks, Ephi. ======================================================================== // c_spam.cpp #include "spam.h" extern "C" Spam* new_Spam(int a, int b) { Spam* spam = new Spam(a, b); return spam; } extern "C" void Spam_Display(Spam* spam) { spam->Display(); } extern "C" void delete_Spam(Spam* spam) { delete spam; } ======================================================================== // c_spam.h #include "spam.h" extern "C" Spam* new_Spam(int a, int b); extern "C" void Spam_Display(Spam* spam); extern "C" void delete_Spam(Spam* spam); ======================================================================== // ext_spam.cpp // spam extension module. #include "Python.h" #include "c_spam.h" static PyObject* ext_new_Spam(PyObject* self, PyObject* args) { int a, b; if (!PyArg_ParseTuple(args, "ii", &a, &b)) return NULL; Spam* spam = new_Spam(a, b); return Py_BuildValue("O", spam); } static PyObject* ext_Spam_Display(PyObject* self, PyObject* args) { Spam* spam; if (!PyArg_ParseTuple(args, "O", &spam)) return NULL; Spam_Display(spam); return Py_BuildValue(""); } static PyObject* ext_delete_Spam(PyObject* self, PyObject* args) { Spam* spam; if (!PyArg_ParseTuple(args, "O", &spam)) return NULL; delete_Spam(spam); return Py_BuildValue(""); } // "method table" static PyMethodDef c_spamMethods[] = { {"new_Spam", ext_new_Spam, 1}, {"Spam_Display", ext_Spam_Display, 1}, {"delete_Spam", ext_delete_Spam, 1}, {NULL,NULL} }; file://Initialization function that registers new methods with Python interpreter. extern "C" void initc_spam() { PyObject *m; m= Py_InitModule("c_spam", c_spamMethods); } ======================================================================== #makefile PPFLAGS = -fpic LFLAGS = CPP = g++ INCLUDE = /usr/include/python1.5 SOURCES = spam.cpp c_spam.cpp ext_spam.cpp OBJECTS = spam.o c_spam.o ext_spam.o TARGET = c_spammodule.so ####### Implicit rules .SUFFIXES: .cpp .cpp.o: $(CPP) $(CPPFLAGS) -c -I$(INCLUDE) $< ####### Build rules all: $(TARGET) $(TARGET): $(OBJECTS) $(CPP) -shared $(OBJECTS) -o $(TARGET) showfiles: @echo $(SOURCES) makefile clean: rm -f *.o rm -f $(TARGET) rm -f tags rm -f core ======================================================================== run: #!/usr/bin/python import c_spam myspam=c_spam.new_Spam(8, 5) c_spam.Spam_Display(myspam) c_spam.delete_Spam(myspam) print "python end" ======================================================================== // spam.cpp #include #include "spam.h" Spam::Spam(int a, int b) : m_a(a), m_b(b) { cout << endl; cout << "In Spam::Spam, "; cout << "m_a = " << m_a << " m_b = " << m_b << endl; } void Spam::Display() { cout << "In Spam::Display, "; cout << "m_a = " << m_a << " m_b = " << m_b << endl; } Spam::~Spam() { cout << "In Spam::~Spam, "; cout << "m_a = " << m_a << " m_b = " << m_b << endl; } ======================================================================== // spam.h class Spam { public: Spam(int a, int b); void Display(); ~Spam(); private: int m_a; int m_b; }; ======================================================================== From mhammond at skippinet.com.au Wed Nov 24 09:53:15 1999 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 24 Nov 1999 19:53:15 +1100 Subject: [C++-SIG] Python calling C++ issues In-Reply-To: <003401bf3655$ec6dc480$b7e856ce@london> Message-ID: <003301bf3659$590aea20$0501a8c0@bobcat> > Unfortunately, we don't seems to understand what do you mean > by "Object". Is > it something we need to define or is it already defined in a > h file that we > forgot to include. We use Linux/gcc environment. Sorry - I meant "PyObject" > Also, in our sample, we did not use virtual function Hmmm - OK - my advice could well be wrong. Unless your C compiler always adds a vfptr. I have seen this problem (when using virtuals) before and the symptoms sound almost identical. Try the code snippet I posted, and see if the debugger does show the "PyObject *" and the "Spam *" as different values, even though they are pointing to the same object. Otherwise Im afraid I have no idea... Mark. From ephi.dror at cis.canon.com Wed Nov 24 19:46:19 1999 From: ephi.dror at cis.canon.com (Dror, Ephi) Date: Wed, 24 Nov 1999 10:46:19 -0800 Subject: [C++-SIG] Python calling C++ issues Message-ID: <5865800428DFD21199020090274E8C9554B4D0@cisncdc.cissv.canon.com> Hi Mark, Thanks a lot again. We tried it but unfortunately it did not help in our case. Does anyone know where can we download C++ based debug version of Python 1.52 for Linux? Our next step is to use Python 1.52 which is compiled with C++ and possibly a debug version and then try our little sample. Thanks a lot. Ephi. -----Original Message----- From: Mark Hammond [mailto:mhammond at skippinet.com.au] Sent: Wednesday, November 24, 1999 12:53 AM To: 'Ephi Dror'; c++-sig at python.org Subject: RE: [C++-SIG] Python calling C++ issues > Unfortunately, we don't seems to understand what do you mean > by "Object". Is > it something we need to define or is it already defined in a > h file that we > forgot to include. We use Linux/gcc environment. Sorry - I meant "PyObject" > Also, in our sample, we did not use virtual function Hmmm - OK - my advice could well be wrong. Unless your C compiler always adds a vfptr. I have seen this problem (when using virtuals) before and the symptoms sound almost identical. Try the code snippet I posted, and see if the debugger does show the "PyObject *" and the "Spam *" as different values, even though they are pointing to the same object. Otherwise Im afraid I have no idea... Mark. _______________________________________________ C++-SIG maillist - C++-SIG at python.org http://www.python.org/mailman/listinfo/c++-sig