From furnish at actel.com Thu Apr 29 09:00:44 1999 From: furnish at actel.com (Geoffrey Furnish) Date: Thu, 29 Apr 1999 00:00:44 -0700 (PDT) Subject: [C++-SIG] Restarting Message-ID: <14120.924.420287.392618@zork.actel.com> Hello all, I'd like to revive this sig. I know I've been quiet of late, but hey, so has everyone else. In the interest of restarting the discussion, I guess I'll try to restate what I think we need to accomplish here. But I represent it only as my opinion. I hope others will comment, or suggest wholly different agendas, whatever. Anyway, this post is just intended to kick start renewed discussion of what the goals should be and the means for achieving them. First off, "THE GOAL", in my mind, is to come up with a set of core enabling code that would ultimately be directly absorbed by Guido into the Python distribution. When it's all said and done, I want Python extension programmers to be able to pull down a stock distribution, and using that, write extension modules in C++ with the full conveniences accorded by the C++ language. A lot of the action for Python, in the circles I travel, is in the business of hooking Python up to other code. I frequently find myself writing this "glue code" that we call Python compiled extensions, which talks to Python's C api in a pretty low level C-ish way, and talks to other compiled assets, using fairly upscale C++. I'd like the code which lives in this space, to be able to talk to the Python API in a similarly upscale fashion. I've discussed this with Guido a few times over the last two years. He's a little concerned about the idea of absorbing too much code that he doesn't understand, into the core, because of the support issues. And he wants to see a serious consensus emerge on the SIG. [Guido, please feel free to further clarify here]. Both of these seem like very reasonable issues to me, but I'm optimistic that both can be satisfactorily redressed. Regarding the first point, I figure that much of the C++ support machinery that I envision being developed in this SIG, is pretty lightweight stuff. For example, the CXX_Objects package that Paul has been distributing, is a pretty thin veneer over the Python C API, which happens to really make life a lot easier on the Python extension programmer working in C++, without really representing all that much code. I think that is representative of how most of the work of this SIG can come out. Moreover, I think there's a pretty good set of dividing lines between some of the different subsystems, so that we should be able to advocate some of them to Guido for inclusion into the core Python distribution, without necessarily having to couch it as an all-or-nothing kind of arrangement. As for consensus, well, everybody speak up! In the sig charter, I proposed the following list of example topics for this sig. I'll just quote that list, and insert some comments betwinst. > 1.Autoconf support for enabling C++ support in Python. This must be > managed in a way which does not change the C API, or the behavior of > Python if not configured for C++ support, in any (observable?) way. In > other words, conventional C extension modules must continue to work, > whether Python is configured with C++ support or not. I've recently produced a new patch set for fixing the Python-1.5.2 configure script to support C++. Yell loud if you don't agree, but I'm under the impression that there is a pretty universal awareness of the basic issue that we need main() compiled in C++ in order to support the possibility of the python executable hosting other C++ code buried in extension modules. This much we need, and I anticipate we can all agre on, almost irrespective of exactly /what/ the specific C++ interface we come up with is. Or stated another way, people wanting to write Python extension modules in C++ will need this, no matter exactly what they do for the rest of the C++ binding. I will put the latest version of this patch up on the C++ Sig web site soon. I have a little learning to do about how to administer the www site for this sig, but as soon as I can, I'll post a patch against the 1.5.2 distribution which adds autoconf support for C++ enabled python configurations. > 2.Type safety in the Python API. There's a lot here, but one of the most basic things I was thinking about when I wrote that, was this business of parsing tuples, especially arg tuples. Right now you do this with a format string, and you'd better do it right! What I'd like to see instead, is a system that uses C++'s innate awareness of the types of identifiers, to directly construct those format strings on your behalf. There are probably similar issues involved with extracting elements from the various Python containers. > 3.Introducing C++ classes for the various major Python abstractions, > such as dictionaries, lists, tuples, modules, etc. Paul and I spent some real time talking over this when I was at LLNL, and his CXX_Objects package is a really good incarnation of the basic ideas I think are important here. I've got to get reacquainted with the Python C aPI and see how much coverage we have right now. A pretty basic way of saying what classes I figure we need, is to look at the list of all Python C API entry points. They all look sort of like: Py_. To me, this would seem to translate naturally to: namespace Py { class { PyObject *( ... ); The idea then is to come up with C++ classes representing the major subdivisions of the Python C API, with member functions corresponding to the various function entry points in this package family in the C API. That's at least a pretty decent first approximation to what should be done. A little additional work to bring [] subscripting operators to Dicts and so forth, seems prudent as well. So anyway, I think Paul's CXX_Objects thing looks to me like a pretty significant step along the path toward "wrapping" the Python C API. > 4.Providing semantics for these classes which are natural both to the > Python programmer, as well as the C++ programmer. For example, the > PyDict class should have an operator[], and should also support STL > style iterators. Many issues of this form. Here I was trying to say that the wrapper classes implemented above, should be good STL citizens. However, that was only loosely defined at the time that I wrote it. Now I would point to the recently published "Generic Programming and the STL" by Matt Austern, which contains comprehensive documentation of the services exported by the STL components. We should try to make our classes that wrap the Python C API, support the services of similarly named STL classes as much as possible. There may be some issues here of just how far we can go with this. Python is very dynamically typed, and C++ is statically typed. For instance, a PyDict holds PyObject *'s, not int's. So there may be some issues about just how "normal" we can make the Python C++ wrapper classes look, in comparison to their STL counterparts, but we should do what we can. In particular, I think it ought to be possible to to at least implement enough services to support a wide sampling of the STL algorithms, operating over the elements of the Python containers. For example, maybe we need to write a functor library so you can write something like: Py::Dict a; // Fill a with elements, either from C++ or from Python script // language. sort( a.begin(), a.end(), PyLexicographicalLess() ); Or whatever. Anyway, hopefully you can understand the basic idea I'm trying to convey. > 5.Method invocation. How to make the invocation of C++ member > functions as natural and/or painless as possible. I have code that makes it possible to invoke methods of an object in the Python language, and have it result in invoking methods of an underlying C++ object. I'll dust that code off and try to post it soon. There were some comments on this code about a year ago, and I tried to fold in some of the constructive criticisms that I received, when last I rewrote that. Anyway, I'll get that cleaned up, and post it to the www site so poeople can look it over. > 6.Error handling. How to irradicate NULL checking in favor of C++ > style exceptions. I really want to expunge this business of NULL checking of the results of Python C API calls. The wrapper classes envisioned above, should do that, and throw appropriate exceptions when something goes gonzo in the C aPI functions they call. Then in the C++ code which uses these wrapper classes, you could replace all blecherous NULL checking, with a conventional C++ try block. Or even just let it go unhandled, if you have been suitably rigorous in the use of ctor/dtor pairs. For this to work, there needs to be a try/catch block around this methodobject invoker thingie in the Python core. Again, I have code that implements an "exception safe" method invocation semantic. I'll repackage that for 1.5.2, and post it for comment. In any event, I hope people will comment on this, and voice any other views or raise any other issues that ought to be heard and considered by all. Also, if you have code which you think should be considered by the larger community in the context of this effort to codify a C++ interface for Python extension programming, then by all means, send it to me, and I'll try to post it on the SIG www page. We should get all the ideas and competing propositions out on the table where every one can see, review, comment, contribute. One last thing for this initial attempt at revitalizing this SIG. In the past, there has been a lot of talk about the dearth of compilers at the level anticipated by the code that I and Paul have posted. There are some developments on this front that I think are worthing bringing to people's attention: 1) Sun C++ 5.0 is out. Although still a far cry short of "ANSI C++", it is a huge step up over their previous 4.2 product. They left out partial specialization and member templates, which is extremely dissapointing, but still, the overall product is a huge step up over its direct predecessor. 2) MS VC++ 6.0 is reputed to have support for "inline member templates" and most of the rest of the modern template machinery. Evidently it still lacks out of line member templtes, and partial specialization, but--so I am told--on the whole it is a big step forward. 3) For those who may not have heard yet, EGCS has been named the official successor to the GCC throne. This is extremely good news for the C++ community. I've been working with developer snapshots of egcs for several months now. 10/5/98 was the snapshot that marked the viability of egcs in my book. I'm pretty sure that current egcs snapshots will successfully handle code at the level of what Paul and I have put up on this list before. I'll be running precise evaluations of this over the next few days, but I'm pretty sure late model egcs snapshots are "there". Expect a GCC 3.0 shortly, which will be bascially a shaken down release of the current egcs developers snapshots. In other words, we are probably just days or weeks away from having an extremely high quality freeware virtually-ISO C++ compiler. Cheers to all. Please express your views.. -- 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 beazley at cs.uchicago.edu Thu Apr 29 16:47:07 1999 From: beazley at cs.uchicago.edu (David Beazley) Date: Thu, 29 Apr 1999 09:47:07 -0500 (CDT) Subject: [C++-SIG] Restarting References: <14120.924.420287.392618@zork.actel.com> Message-ID: <199904291447.JAA29865@tartarus.cs.uchicago.edu> Geoffrey Furnish writes: > > I've discussed this with Guido a few times over the last two years. > He's a little concerned about the idea of absorbing too much code that > he doesn't understand, into the core, because of the support issues. > And he wants to see a serious consensus emerge on the SIG. [Guido, > please feel free to further clarify here]. > At the risk of having to go find my flame suit, I am opposed to the idea of adding C++ (at the level of sophistication described) to the Python core unless it can be added (or disabled) as an optional feature. Otherwise, I fear that this will be nothing short of a maintenance nightmare for Guido and the rest of us who are quite happy with the current C API. The fact that this "enhancement" only works with a few compilers also suggests that it would create problems for anyone wanting to write a portable extension using this interface. With that said, I'm not entirely opposed to having better C++ support. I can only hope that it is done in a halfway sensible and portable manner. Just my 0.02. Cheers, Dave From dubois1 at llnl.gov Thu Apr 29 16:52:26 1999 From: dubois1 at llnl.gov (Paul F. Dubois) Date: Thu, 29 Apr 1999 07:52:26 -0700 Subject: [C++-SIG] Restarting Message-ID: <000a01be924f$e5a01d60$f4160218@c1004579-c.plstn1.sfba.home.com> Comments about some of the points Geoff made. I will for the sake of discussion point out the capabilities of CXX, but I hope it doesn't sound defensive. I'm not in love with my implementation and if someone has a better idea, or a suggestion for revisions, I am very much open to it. >I will put the latest version of this patch up on the C++ Sig web site >soon. I have a little learning to do about how to administer the www >site for this sig, but as soon as I can, I'll post a patch against the >1.5.2 distribution which adds autoconf support for C++ enabled python >configurations. This would be a big help. I didn't know we had a web site. > > > 2.Type safety in the Python API. > >There's a lot here, but one of the most basic things I was thinking >about when I wrote that, was this business of parsing tuples, >especially arg tuples. Right now you do this with a format string, >and you'd better do it right! What I'd like to see instead, is a >system that uses C++'s innate awareness of the types of identifiers, >to directly construct those format strings on your behalf. There are >probably similar issues involved with extracting elements from the >various Python containers. CXX does not use format strings. Instead, you simply extract the elements of the tuple using index notation. The strong typing occurs because an attempt to construct a CXX class such as List with a python object that isn't a list, will throw an exception. And of course, there are queries available as to type. The CXX test routines illustrate this. I'm not opposed to the PyArg_ParseTuple wrapping, I just didn't find it particularly helpful. > > > 3.Introducing C++ classes for the various major Python abstractions, > > such as dictionaries, lists, tuples, modules, etc. That is there, although some things need work, and some of the more obscure Python objects aren't there, functions being the most notable. (Callable, yes.) > ..> I figure we need, is to look >at the list of all Python C API entry points. They all look sort of >like: Py_. To me, this would seem to translate >naturally to: > >namespace Py { > class { > PyObject *( ... ); I think most of the time we want to be focused on the objects, not the operation. CXX contains a lot of the C API. > A little additional work to bring [] subscripting >operators to Dicts and so forth, seems prudent as well. This is in CXX. > > 4.Providing semantics for these classes which are natural both to the > > Python programmer, as well as the C++ programmer. For example, the > > PyDict class should have an operator[], and should also support STL > > style iterators. Many issues of this form. CXX has both. > >Here I was trying to say that the wrapper classes implemented above, >should be good STL citizens. However, that was only loosely defined >at the time that I wrote it. Now I would point to the recently >published "Generic Programming and the STL" by Matt Austern, which >contains comprehensive documentation of the services exported by the >STL components. We should try to make our classes that wrap the >Python C API, support the services of similarly named STL classes as >much as possible. I tried, but the documentation needed was pretty bad. My classes probably (certainly!) are not going to turn out to be completely correct STL container classes, but they are close. I will get this book. Thanks for the reference. >So there may be >some issues about just how "normal" we can make the Python C++ wrapper >classes look, in comparison to their STL counterparts, but we should >do what we can. CXX sequences are templated on the type of object the iterator returns. > >In particular, I think it ought to be possible to to at least >implement enough services to support a wide sampling of the STL >algorithms, operating over the elements of the Python containers. For >example, maybe we need to write a functor library so you can write >something like: > >Py::Dict a; >// Fill a with elements, either from C++ or from Python script >// language. >sort( a.begin(), a.end(), PyLexicographicalLess() ); This works in CXX, although I didn't particularly experiment with the third argument any, since Python objects have a built-in less. But it should work. > > > > 5.Method invocation. How to make the invocation of C++ member > > functions as natural and/or painless as possible. That's the part I got stuck on. I did succeed in a mechanism for creating C++ classes that are decendents of PyObject and that have the necessary tables and methods for setting them, and which have simple mechanisms for setting the behaviors but one is left with a clumsy gap between the methods of the class and the glue function needed for the behavior or method as a python object. > > 6.Error handling. How to irradicate NULL checking in favor of C++ > > style exceptions. CXX requires no null checking, it is all done with exceptions. But as you and I have discussed, it would be possible perhaps to obviate the need for the try block in user code. It isn't that onerous, but the fact that the try / catch could be hoisted is tempting. >the C++ community. I've been working with developer snapshots of egcs >for several months now. 10/5/98 was the snapshot that marked the >viability of egcs in my book. I'm pretty sure that current egcs >snapshots will successfully handle code at the level of what Paul and >I have put up on this list before I tried about two months ago and it was close but no cigar...it lacked a standard library, for one thing, and support for virtual methods in templated classes. VC++ on Windows does work. But I share your optimism. From furnish at actel.com Thu Apr 29 17:27:50 1999 From: furnish at actel.com (Geoffrey Furnish) Date: Thu, 29 Apr 1999 08:27:50 -0700 (PDT) Subject: [C++-SIG] Restarting In-Reply-To: <37280EFD.F7272B37@onera.fr> References: <14120.924.420287.392618@zork.actel.com> <37280EFD.F7272B37@onera.fr> Message-ID: <14120.31350.11651.597641@zork.actel.com> Marc Poinot writes: > I'm ready to help you in coding, testing or > documenting this, but: > > - We cannot compile CXX_* here, even if we've > a pretty good set of almost-ISO compliant > compilers (DEC, SGI, SUN, and EGCS). Could you post the versions of each of these compilers? And the failure mode for each? Paul's CXX stuff didn't use member templates, so it /really should/ work with all those compilers. He did use namespace Py, which wasn't in Sun C++ 4.2, but is now in 5.0. I know that SGI C++ 7.2+ have the features needed to do CXX as well. For egcs, you'll need a recent snapshot. > - EGCS doesn't handle automatic instanciation > elsewhere than Sun and Linux. We use both > automatic and explicit with our application > and it's not-funny and difficult work. But > we *want* our application run on many platforms. Uhh, this doesn't sound right. egcs does do--or is supposed to do--automatic instantiation on all targets. egcs uses an instantiation model sort of like what people call "the Borland model", (or like what EDG variants call "-pta", if I am remembering right) where the instantiations of /anything seen/ are put in every translation unit, with weak linkage. So, it really ought to work. If you could post your actual failure logs, maybe we could figure out what is going on. Perhaps there was a target specific biff in the snapshot you're using. 19990428 is now up on egcs.cygnus.com. -- 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 poinot at onera.fr Thu Apr 29 17:40:43 1999 From: poinot at onera.fr (Marc Poinot) Date: Thu, 29 Apr 1999 17:40:43 +0200 Subject: [C++-SIG] Restarting References: <14120.924.420287.392618@zork.actel.com> <37280EFD.F7272B37@onera.fr> <14120.31350.11651.597641@zork.actel.com> Message-ID: <37287D7B.E17919@onera.fr> Geoffrey Furnish wrote: > > > - We cannot compile CXX_* here, even if we've > > a pretty good set of almost-ISO compliant > > compilers (DEC, SGI, SUN, and EGCS). > > Could you post the versions of each of these compilers? And the > failure mode for each? Paul's CXX stuff didn't use member templates, > so it /really should/ work with all those compilers. He did use > namespace Py, which wasn't in Sun C++ 4.2, but is now in 5.0. I know > that SGI C++ 7.2+ have the features needed to do CXX as well. For > egcs, you'll need a recent snapshot. > Hmmm... we're late: SGI 7.1, Sun is 4.? and DEC is 6.1, EGCS is 1.1.2 Or you're too fast ? > > - EGCS doesn't handle automatic instanciation > > elsewhere than Sun and Linux. We use both > > automatic and explicit with our application > > and it's not-funny and difficult work. But > > we *want* our application run on many platforms. > > Uhh, this doesn't sound right. egcs does do--or is supposed to > do--automatic instantiation on all targets. egcs uses an > instantiation model sort of like what people call "the Borland model", > (or like what EDG variants call "-pta", if I am remembering right) > where the instantiations of /anything seen/ are put in every > translation unit, with weak linkage. So, it really ought to work. If > you could post your actual failure logs, maybe we could figure out > what is going on. Perhaps there was a target specific biff in the > snapshot you're using. 19990428 is now up on egcs.cygnus.com. > Here is a part of our egcs info file: When used with GNU ld version 2.8 or later on an ELF system such as Linux/GNU or Solaris 2, or on Microsoft Windows, g++ supports the Borland model. On other systems, g++ implements neither automatic model. A future version of g++ will support a hybrid model whereby the compiler will emit any instantiations for which the template definition is included in the compile, and store template definitions and instantiation context information into the object file for the rest. The link wrapper will extract that information as necessary and invoke the compiler to produce the remaining instantiations. The linker will then combine duplicate instantiations. In the mean time, you have the following options for dealing with template instantiations: etc... Marcvs [alias But I'm going to look for a new version of EGCS...] From furnish at actel.com Thu Apr 29 18:04:04 1999 From: furnish at actel.com (Geoffrey Furnish) Date: Thu, 29 Apr 1999 09:04:04 -0700 (PDT) Subject: [C++-SIG] Restarting In-Reply-To: <199904291447.JAA29865@tartarus.cs.uchicago.edu> References: <14120.924.420287.392618@zork.actel.com> <199904291447.JAA29865@tartarus.cs.uchicago.edu> Message-ID: <14120.33524.187016.316996@zork.actel.com> David Beazley writes: > Geoffrey Furnish writes: > > > > I've discussed this with Guido a few times over the last two years. > > He's a little concerned about the idea of absorbing too much code that > > he doesn't understand, into the core, because of the support issues. > > And he wants to see a serious consensus emerge on the SIG. [Guido, > > please feel free to further clarify here]. > > > > At the risk of having to go find my flame suit, I am opposed to the > idea of adding C++ (at the level of sophistication described) to the > Python core unless it can be added (or disabled) as an optional > feature. The autoconf patch I will post, introduces a --with-cxx= option. If you /don't/ configure with --with-cxx, then you get just the usual Python build. If you /do/ configure --with-cxx, then you get main() compiled with C++, which makes global ctors get bootstrapped, and you /could/ depending on what we all work out here, perhaps get another translation unit folded into the build, with some C++ support. I do not propose a trojan horse. I propose a configure time selectable additional support facility for C++ based extension writing. > Otherwise, I fear that this will be nothing short of a > maintenance nightmare for Guido and the rest of us who are quite happy > with the current C API. I've heard this man times, but I don't really think what we're talking about here is that big a deal. Sure, if one doesn't know /any/ C++, I suppose anything could look a little intimidating. But the Python/C++ code I envision, is pretty tame. What you can do with it, sure, that's supposed to be aggressive. But the actual support facility itself, that I think should be bundled with the Python distribution, is not rocket science. > The fact that this "enhancement" only works with a few compilers > also suggests that it would create problems for anyone wanting to > write a portable extension using this interface. I think its important to project a sense of calm on this topic. We should all keep in mind that C++ got its first official international standard, in July of 98. C was standardized in '89. The quality of C++ implementations has been improving at a never-before-seen rate of convergence. egcs in particular, is by now better than practically every vendor compiler on the market, by a wide margin, and is free. Only the EDG strains, and maybe the IBM Visual Age C++ compiler, are actually better in an objective sense. The egcs strain that I'm talking about hasn't been "released" yet, but authoritative word on the street says, "keep your eyes open". > With that said, I'm not entirely opposed to having better C++ > support. I can only hope that it is done in a halfway sensible > and portable manner. Just my 0.02. Well, I hope you will define those terms a little more precisely. No need for the flame suit, but please do just say clearly what you mean. I don't know what part of what has been proposed looks "nonsensical" to you, and also "portable" is not a very precise word. To me, "portability" is best achieved by writing to an ISO standard. The company I work for now, for instance, has been playing the portability game according to the rules of Sun and Microsoft for a long time. The result is that our code base has hundreds of constructs that are flat out illegal according to the ISO C++ stnadard, and /will not complie/ with gcc or KCC. Is that "portable"? Not in my book. Sun and MS love it, ISO won't recognize it. I don't call that "portable". Okay, so suppose we consider "ISO C++" to be the measuring stick for Py::C++ bindings. Then we can consider the fact that not all vendor compilers currently in service on the workstations of all Python users, will compile the code. What conclusion is to be drawn? That we should down grade the Py::C++ code so that it compiles on a subset of the language which is disjoint with any official standards document, and is consequently not even actually clearly defined in writing anywhere in the world--or that maybe some people need better compilers in order to use the code? Which viewpoint is actually harsher on the Python customer? Remember, we are not proposing that any of this code be introduced in a way that would require /all/ Python customers to "go get new compilers". configure without --with-cxx, and all is as before. So people who want to use the C++ binding, would need compilers up to a certain grade. What grade should that be? Remember, egcs is free, and is extremely close to total ISO compliance at this point, and moreover, is going to be relabeled as GCC 3.0 shortly. Maybe it would be useful to be even more specific. Then people can comment on this one feature at a time, rather than Yes/No ISO. I think the Python C++ bindings should live in namespace Py. I think we should keep avoid use of partial specialization since MS won't have it until at least VC++ 7.0. I think we should avoid having any part of the C++ binding /depend/ on member templates, because Sun 5.0 doesn't have them. I think we should provide some conveniences as optional facilities that are implemented with member templates. By making these "inline member templates", they'll work with MS VC++ 6.0, Code Warior, EDG variants, egcs. Perhaps this could be controlled via "member template autodetection" in the configure, resulting in a config.h flag that would allow CPP based inclusion or exclusion of these facilities, depending on whether the compiler the user is using at configure time, is up to the task or not. Peronally, I see this as a very sensible, extremely portable, deployment plan. What do David and others think? -- 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 andreie at spam.ee Thu Apr 29 18:21:52 1999 From: andreie at spam.ee (Andrei Errapart) Date: Thu, 29 Apr 1999 19:21:52 +0300 (EEST) Subject: [C++-SIG] Restarting In-Reply-To: <000a01be924f$e5a01d60$f4160218@c1004579-c.plstn1.sfba.home.com> Message-ID: On Thu, 29 Apr 1999, Paul F. Dubois wrote: [] > >the C++ community. I've been working with developer snapshots of egcs > >for several months now. 10/5/98 was the snapshot that marked the > >viability of egcs in my book. I'm pretty sure that current egcs > >snapshots will successfully handle code at the level of what Paul and > >I have put up on this list before > > I tried about two months ago and it was close but no cigar...it lacked a > standard library, for one thing, and support for virtual methods in > templated classes. VC++ on Windows does work. But I share your optimism. Recent egcs snapshots should handle virtual methods in templated classes, at least the ones in the CXX. Don't know much about standard library, but CXX was quite satisfied with the GNU c++ library. Well, I don't work actively with python, C++ and CXX anymore and things might have changed a bit. Andrei From beazley at cs.uchicago.edu Thu Apr 29 18:29:06 1999 From: beazley at cs.uchicago.edu (David Beazley) Date: Thu, 29 Apr 1999 11:29:06 -0500 (CDT) Subject: [C++-SIG] Restarting References: <14120.924.420287.392618@zork.actel.com> <199904291447.JAA29865@tartarus.cs.uchicago.edu> <14120.33524.187016.316996@zork.actel.com> Message-ID: <199904291629.LAA29958@tartarus.cs.uchicago.edu> > > Peronally, I see this as a very sensible, extremely portable, > deployment plan. What do David and others think? > I think the proposed configuration plan and optional nature of this addition sound fine. Since I am still a bit of a C++ skeptic, I am somewhat wary of C++ portability claims despite the existence of a "standard." However, I agree with you that this could be a non-issue in a few years (at least one would hope :-). Cheers, Dave From da at ski.org Thu Apr 29 18:33:19 1999 From: da at ski.org (David Ascher) Date: Thu, 29 Apr 1999 09:33:19 -0700 (Pacific Daylight Time) Subject: [C++-SIG] Restarting In-Reply-To: <199904291447.JAA29865@tartarus.cs.uchicago.edu> Message-ID: On Thu, 29 Apr 1999, David Beazley wrote: > Geoffrey Furnish writes: > > > > I've discussed this with Guido a few times over the last two years. > > He's a little concerned about the idea of absorbing too much code that > > he doesn't understand, into the core, because of the support issues. > > And he wants to see a serious consensus emerge on the SIG. [Guido, > > please feel free to further clarify here]. > > > > At the risk of having to go find my flame suit, I am opposed to the > idea of adding C++ (at the level of sophistication described) to the > Python core unless it can be added (or disabled) as an optional > feature. FWIW, I read Geoffrey's email as implying a configure-time --c++ switch. In other words, adding or disabling is a compile-time specification. I might have been wrong. On the topic of compilers, I'm much more optimistic now than when this issue was first brought up. If it turns out as Geoffrey (somewhat indirectly) predicts that Windows, Solaris and GCC are all "ok", then that in my opinion would make the C++ coverage enough to warrant its inclusion in the core -- at the same level as thread support for example. --david From vanandel at ucar.edu Thu Apr 29 18:45:02 1999 From: vanandel at ucar.edu (Joe Van Andel) Date: Thu, 29 Apr 1999 10:45:02 -0600 Subject: [C++-SIG] Restarting References: <14120.924.420287.392618@zork.actel.com> Message-ID: <37288C8E.D77A4A9D@ucar.edu> FYI: I've been using the 19990418 EGCS snapshot with CXX. I still needed a patch to the compiler's handling of inlining, to make it work, but it now compiles my CXX based code. Template handling seems to slow down EGCS noticably, but it is still usable. And yes, it is great news that EGCS will be the mainstream GCC. -- Joe VanAndel Internet: vanandel at ucar.edu National Center for http://www.atd.ucar.edu/~vanandel/ Atmospheric Research From phil at geog.ubc.ca Thu Apr 29 18:23:27 1999 From: phil at geog.ubc.ca (Phil Austin) Date: Thu, 29 Apr 1999 09:23:27 -0700 (PDT) Subject: [C++-SIG] Restarting In-Reply-To: <000a01be924f$e5a01d60$f4160218@c1004579-c.plstn1.sfba.home.com> References: <000a01be924f$e5a01d60$f4160218@c1004579-c.plstn1.sfba.home.com> Message-ID: <14120.34687.338972.104104@brant.geog.ubc.ca> Paul F. Dubois writes: > > I tried [egcs] about two months ago and it was close but no cigar...it lacked a > standard library, for one thing, and support for virtual methods in > templated classes. VC++ on Windows does work. But I share your optimism. > Joe Van Andel posted a message to the egcs-bugs list last week indicating that he'd succeeded in getting CXX to compile with the current snapshot, after applying a patch that restricted agressive inlining. I'm not sure whether he's tested it further. Phil Phil Austin INTERNET: phil at geog.ubc.ca (604) 822-2175 FAX: (604) 822-6150 http://www.geog.ubc.ca/~phil Atmospheric Sciences Programme Department of Earth and Ocean Sciences Geography #217 University of British Columbia 1984 W Mall Vancouver, BC V6T 1Z2 CANADA From vanandel at ucar.edu Thu Apr 29 20:32:07 1999 From: vanandel at ucar.edu (Joe Van Andel) Date: Thu, 29 Apr 1999 12:32:07 -0600 Subject: [C++-SIG] Restarting References: <001201be9269$da30b880$f4160218@c1004579-c.plstn1.sfba.home.com> Message-ID: <3728A5A7.5A659088@ucar.edu> The egcs snapshots are on: ftp://egcs.cygnus.com/pub/egcs/snapshots/index.html I've attached the patch to this mail. -- Joe VanAndel Internet: vanandel at ucar.edu National Center for http://www.atd.ucar.edu/~vanandel/ Atmospheric Research -------------- next part -------------- *** integrate.c.orig Tue Apr 20 16:26:50 1999 --- integrate.c Tue Apr 20 16:32:19 1999 *************** *** 121,126 **** --- 121,130 ---- register tree parms; rtx result; + /* We place a limit on even functions marked as inline. */ + if (DECL_INLINE (fndecl)) + max_insns *= 100; + /* No inlines with varargs. */ if ((last && TREE_VALUE (last) != void_type_node) || current_function_varargs) *************** *** 136,142 **** return current_function_cannot_inline; /* If its not even close, don't even look. */ ! if (!DECL_INLINE (fndecl) && get_max_uid () > 3 * max_insns) return N_("function too large to be inline"); #if 0 --- 140,146 ---- return current_function_cannot_inline; /* If its not even close, don't even look. */ ! if ( get_max_uid () > 3 * max_insns) return N_("function too large to be inline"); #if 0 *************** *** 170,176 **** return N_("function with transparent unit parameter cannot be inline"); } ! if (!DECL_INLINE (fndecl) && get_max_uid () > max_insns) { for (ninsns = 0, insn = get_first_nonparm_insn (); insn && ninsns < max_insns; --- 174,180 ---- return N_("function with transparent unit parameter cannot be inline"); } ! if (get_max_uid () > max_insns) { for (ninsns = 0, insn = get_first_nonparm_insn (); insn && ninsns < max_insns; From poinot at onera.fr Fri Apr 30 10:12:11 1999 From: poinot at onera.fr (Marc Poinot) Date: Fri, 30 Apr 1999 10:12:11 +0200 Subject: [C++-SIG] Restarting References: <14120.924.420287.392618@zork.actel.com> <37280EFD.F7272B37@onera.fr> <14120.31350.11651.597641@zork.actel.com> Message-ID: <372965DB.C8590F36@onera.fr> Geoffrey Furnish wrote: > > Could you post the versions of each of these compilers? And the > failure mode for each? Paul's CXX stuff didn't use member templates, > so it /really should/ work with all those compilers. > Using the DEC v6.1 compiler (with some modifications because IOstream is out of std namespace), I failed with distribution 11 (see end of mail). Maybe it's a problem of incomplete template instanciation? Any tips? > > - EGCS doesn't handle automatic instanciation > > elsewhere than Sun and Linux. We use both > > automatic and explicit with our application > > and it's not-funny and difficult work. But > > we *want* our application run on many platforms. > > Uhh, this doesn't sound right. egcs does do--or is supposed to > do--automatic instantiation on all targets. > I tried again with last snapshot, it fails. I also get binutils to have the gnu ld but it fails on an as option. I can send you (or cygnus) the trace, I feel like a get-the-next-gnu-tool-to-go-further problem... Marcvs [alias Then, once again I'm frustrated :{ And I'm going back to Python code :] --- PYTHON LINE --- CROSS AT YOUR OWN RISK --- cxx: Error: /usr/include/cxx/algorithm, line 742: no instance of overloaded function "value_type" matches the argument list argument types are: (Py::SeqBase::iterator) detected during: instantiation of "void std::__quick_sort_loop(RandomAccessIterator, RandomAccessIterator) [with RandomAccessIterator=Py::SeqBase::iterator]" at line 834 instantiation of "void std::sort(RandomAccessIterator, RandomAccessIterator) [with RandomAccessIterator=Py::SeqBase::iterator]" at line 205 of "./Demo/example.cxx" __quick_sort_loop_aux(first, last, _RWSTD_VALUE_TYPE(first)); ---------------------------------------^ cxx: Error: /usr/include/cxx/algorithm, line 742: no instance of overloaded function "__quick_sort_loop_aux" matches the argument list argument types are: (Py::SeqBase::iterator, Py::SeqBase::iterator, ) detected during: instantiation of "void std::__quick_sort_loop(RandomAccessIterator, RandomAccessIterator) [with RandomAccessIterator=Py::SeqBase::iterator]" at line 834 instantiation of "void std::sort(RandomAccessIterator, RandomAccessIterator) [with RandomAccessIterator=Py::SeqBase::iterator]" at line 205 of "./Demo/example.cxx" __quick_sort_loop_aux(first, last, _RWSTD_VALUE_TYPE(first)); ----^ cxx: Error: /usr/include/cxx/algorithm.cc, line 1082: no instance of overloaded function "value_type" matches the argument list argument types are: (Py::SeqBase::iterator) detected during: instantiation of "void std::__insertion_sort(RandomAccessIterator, RandomAccessIterator) [with RandomAccessIterator=Py::SeqBase::iterator]" at line 1118 instantiation of "void std::__final_insertion_sort(RandomAccessIterator, RandomAccessIterator) [with RandomAccessIterator=Py::SeqBase::iterator]" __linear_insert(first, i, _RWSTD_VALUE_TYPE(first)); --------------------------------------^ cxx: Error: /usr/include/cxx/algorithm.cc, line 1082: no instance of overloaded function "__linear_insert" matches the argument list argument types are: (Py::SeqBase::iterator, Py::SeqBase::iterator, ) detected during: instantiation of "void std::__insertion_sort(RandomAccessIterator, RandomAccessIterator) [with RandomAccessIterator=Py::SeqBase::iterator]" at line 1118 instantiation of "void std::__final_insertion_sort(RandomAccessIterator, RandomAccessIterator) [with RandomAccessIterator=Py::SeqBase::iterator]" __linear_insert(first, i, _RWSTD_VALUE_TYPE(first)); ------------^ cxx: Error: /usr/include/cxx/algorithm, line 805: no instance of overloaded function "value_type" matches the argument list argument types are: (Py::SeqBase::iterator) detected during: instantiation of "void std::__unguarded_insertion_sort(RandomAccessIterator, RandomAccessIterator) [with RandomAccessIterator=Py::SeqBase::iterator]" at line 1119 of "/usr/include/cxx/algorithm.cc" instantiation of "void std::__final_insertion_sort(RandomAccessIterator, RandomAccessIterator) [with RandomAccessIterator=Py::SeqBase::iterator]" __unguarded_insertion_sort_aux(first, last, _RWSTD_VALUE_TYPE(first)); ------------------------------------------------^ cxx: Error: /usr/include/cxx/algorithm, line 805: no instance of overloaded function "__unguarded_insertion_sort_aux" matches the argument list argument types are: (Py::SeqBase::iterator, Py::SeqBase::iterator, ) detected during: instantiation of "void std::__unguarded_insertion_sort(RandomAccessIterator, RandomAccessIterator) [with RandomAccessIterator=Py::SeqBase::iterator]" at line 1119 of "/usr/include/cxx/algorithm.cc" instantiation of "void std::__final_insertion_sort(RandomAccessIterator, RandomAccessIterator) [with RandomAccessIterator=Py::SeqBase::iterator]" __unguarded_insertion_sort_aux(first, last, _RWSTD_VALUE_TYPE(first)); ----^ cxx: Info: 6 errors detected in the compilation of "./Demo/example.cxx".