tkacik@rphroy.UUCP (Tom Tkacik) (10/10/89)
We are starting a large software project, and are considering using C++ as the implementation language. It is expected that this will be used by many people, and will have to be maintained by different people, on several different systems. Is C++ ready for use yet? I have heard of several different versions of C++. AT&T C++ ver. 1.2, AT&T C++ ver. 2.0, g++-1.35, Zortech C++, etc. and that there are differences between them. I am questioning the stability of C++. How much further change will there be? Should we go ahead and use the C++ 1.2 that we got from our vendor? Should we attempt to get the new version 2.0? Is g++-1.35 (or 1.36?) ready for use, and similar enough to C++2.0 that we will not notice the difference? Basically, 1) are the differences between the different current versions small enough that code will be portable between them, and 2) will future changes to the language be small enough that we will not have to change much of the code in the future? Thank You. -- --- Tom Tkacik GM Research Labs, Warren MI 48090 uunet!edsews!rphroy!megatron!tkacik Work Ph: (313)986-1442 "If you can't stand the bugs, stay out of the roach-motel." Ron Guilmette
dog@cbnewsl.ATT.COM (edward.n.schiebel) (10/11/89)
From article <17898@rphroy.UUCP>, by tkacik@rphroy.UUCP (Tom Tkacik): > We are starting a large software project, and are considering using C++ > as the implementation language. It is expected that this will be used by > many people, and will have to be maintained by different people, on several > different systems. > > Is C++ ready for use yet? YES! > I have heard of several different versions of C++. > AT&T C++ ver. 1.2, AT&T C++ ver. 2.0, g++-1.35, Zortech C++, etc. > and that there are differences between them. The latest and most up-to-date is AT&T's Releasee 2.0. FSF's g++ is right there too, but deviates from the specifications in the C++ Reference Manual in a few ways. > > I am questioning the stability of C++. How much further change will there be? > Should we go ahead and use the C++ 1.2 that we got from our vendor? > Should we attempt to get the new version 2.0? Definitly go for Release 2.0. > Is g++-1.35 (or 1.36?) ready for use, and similar enough to C++2.0 that we will > not notice the difference? Depends on the features of g++ you use that C++ doesn't support and visa-versa. I wish I could give you details, but I am not intimate with g++. > > Basically, 1) are the differences between the different current versions small > enough that code will be portable between them, and > 2) will future changes to the language be small enough that we > will not have to change much of the code in the future? There are significant differences (improvements!) between C++ 1.2 and 2.0. Use a 2.0 based product (of which g++ is a very close relative). A short anecdote: I attended the Usenix C++ Workshop in Santa Fe to gear myself up for a new project we were going to write in C++. One of the speakers presented his view that itwould take a year to learn C++/object-oriented programming. Well I was distraught. I spoke to Bjarne about this and he agreed it would take the time BUT at the end of the year the project would be much farther along than if we had gone with C. I took his advice and he was right. We accomplished things I seriously doubt would have been possible otherwise. Go for it! Ed Schiebel AT&T Bell Laboratories dog@vilya.att.com
gregk@cbnewsm.ATT.COM (gregory.p.kochanski) (10/11/89)
As a relatively long-time user of C++ (over 1 year!), I'd say it's useable. I suffer withdrawl symptoms when I have to program in C. AT&T C++ 2.0 seems (based on a week of use) to be pretty bulletproof, and the class libraries are quite useful. Trash your AT&T C++ 1.2 versions; 2.0 is a major improvement. As far as the various versions go, they are almost upwards compatible. If you have someone around who understands the old code, it is simple to make the few changes necessary to go from 1.2 to 2.0. Even without understanding of the code, I expect that it wouldn't be hard. I haven't tried G++, but I have tried Glockenspiel's 1.2 port to MS-DOS. It worked well, but did not have the memory to compile anything large (this is as of 9 months's ago). Zortech can handle large programs, and is excellent for learning C++, but version 1.07 had too many bugs to be used for a serious project. Zortech will be out with a new version soon (I've recieved a beta test copy); it is improved, but the beta test version has bugs (of course), so it's useability will depend on whether or not they do a good clean-up job on the final release. Sorry for the advertisement, but that is truth as I see it. My opinions are my own; companies don't have opinions, just policies. Greg Kochanski AT&T Bell Laboratories gpk\@physics.att.com ...!att!physics!gpk
vaughan@mcc.com (Paul Vaughan) (10/13/89)
Don't expect to use gnu g++ 1.35.x for work involving multiple inheritance. There are also other 2.0 'isms that g++ 1.35 will not handle. There is a prerelease of g++ 1.36 available that has been sufficient to support my uses of multiple inheritance, but the official g++ 1.36 has not yet been released. My experience with a slightly out-of-date prerelease of 1.36 is that virtual base classes do not work. I've noticed that the prerelease fixes a few 2.0 'isms that 1.35 didn't handle, but I certainly haven't tested it exhaustively. This is a slightly different topic, but it might be valuable info. I have been mixing 1.35 compiled code with 1.36.0- compiled code without difficulty. I've had to do this because the InterViews library cannot be compiled with 1.36 (it is still 1.2 compatible, after all). I sometimes swap back and forth between compilers because the "other" one sometimes gives better error messages before crashing. I compile anything that involves MI with 1.36.0-. The one problem I have had with linking code from the two compilers is that I have to be sure to declare any 1.35 compiled functions to be overloaded before I can use them in the 1.36 code. This is only a problem for ordinary (non-member) functions though. I have unresolved problems when InterViews .h files include inline function definitions that have 1.2 'isms in them (such as assigning to "this"). I suspect I will have to modify the library code, if the InterViews crew doesn't do it for me. Take this message in perspective. That is, at the moment, the official g++ release is not up to MI. It probably will be soon. It seems that ATT leapfrogged FSF in quality assurance this time, but that isn't too surprising considering they were writing the spec and FSF could only guess. Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan
psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (10/16/89)
In article <17898@rphroy.UUCP>, tkacik@rphroy.UUCP (Tom Tkacik) writes: > We are starting a large software project, and are considering using C++ > as the implementation language. It is expected that this will be used by > many people, and will have to be maintained by different people, on several > different systems. This, more than anything, is probably the crux of the question. Unless you just want to use C++ as a "better C", you should use C++ on a new project, rather as part of maintenance of existing code (which is unlikely to be object oriented!-) But you should probably use it on a small project first. And you darned well had better be prepared to pay the education costs, in staff-hours more than in dollars. (All of this is true for *any* new software technology, be it a new language or CASE or inspections or whatever.) (Well, surely inspections are good on old code, but that's not important right now.*) > Is C++ ready for use yet? I have heard of several different versions of C++. > AT&T C++ ver. 1.2, AT&T C++ ver. 2.0, g++-1.35, Zortech C++, etc. > and that there are differences between them. Not the least of them being the platforms they support. Zortech C++ runs under MS-DOS. G++ never will. AT&T cfront 1.2 has been ported; 2.0 is presumably being ported by the same folks as we speak. > I am questioning the stability of C++. How much further change will there be? > Should we go ahead and use the C++ 1.2 that we got from our vendor? Yes. > Should we attempt to get the new version 2.0? Yes. You should be aware of the differences, and prepare to deal with them; that mostly means taking advantage of the new 2.0 features. But you can certainly write code that compiles under both versions. It may take some work, but not much. (I've done this.) > Basically, 1) are the differences between the different current > versions small enough that code will be portable between them, and I think so. > 2) will future changes to the language be small enough that we > will not have to change much of the code in the future? Probably; but you'll probably want to. The features on the horizon (no promises here, from me or the compay) are parameterized types and exception handling. With those in place, we should then see some nice general-purpose classes. > Tom Tkacik, uunet!edsews!rphroy!megatron!tkacik Paul S. R. Chisholm, AT&T Bell Laboratories att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind. *And don't call me Shirley!
wmm@sdti.com (William M. Miller) (10/19/89)
In article <5286@cbnewsm.ATT.COM> gregk@cbnewsm.ATT.COM (gregory.p.kochanski,mh,) writes: >Zortech will be out with a new version soon (I've recieved a beta test >copy); it is improved, but the beta test version has bugs (of course), I called Zortech this morning. The new 2.0-compatible version will be available November 1, with a $40 upgrade fee to current owners. Alternatively, they can upgrade to a "developers' version" that includes the new C++ debugger, the toolkit, and the library source for $300. (Retail pricing is $200/$450 for the two items.) -- Non-disclaimer: My boss and I always see eye-to-eye (every time I look in the mirror). ...!genrad!mrst!sdti!wmm
wmm@sdti.com (William M. Miller) (10/19/89)
In article <17898@rphroy.UUCP> tkacik@rphroy.UUCP (Tom Tkacik) writes: >Is C++ ready for use yet? Yes, definitely. It has been used profitably in many situations already. Bjarne and company are *extremely* careful about the evolution of the language, and upward compatibility of existing code is one of the most important factors they consider. >I am questioning the stability of C++. How much further change will there be? There is a major change between 1.2 and 2.0. The most important features of that change were multiple inheritance, type-safe linkage, better control over storage allocation, and some new overloadable operators, although a number of other important things were also included. The current Zortech compiler is at a not-quite 1.2 level, although mostly compatible except for bugs; a 2.0 compiler is slated to be available on November 1. However, the only large areas of additional features currently anticipated as relatively near-term items are parameterized types (templates) and exception handling. The parameterized type design was published in the 1988 USENIX C++ Conference Proceedings, and while there has been no iron- clad guarantee that the final design will be identical in every respect, I believe it will be quite similar. The proposed exception handling mechanism will be the subject of a paper presented by Bjarne and Andy Koenig at the C++ at Work conference the first week of November, so nearly everything will be known in broad outline and in most significant details within a month. Another stabilizing factor (I hope!) is the formation of an ANSI standard C++ Committee. The organizational meeting of X3J16 will be held in Washington on December 5. The fact that the industry is willing to form a standard committee at this stage of C++'s development is, I think, a reflection of the belief that the language is relatively mature and will not continue evolving rapidly for very much longer. >Should we go ahead and use the C++ 1.2 that we got from our vendor? Yes. As I said, 2.0 is nearly completely upward compatible. Aside from a couple of minor items (e.g., the fact that the declaration of any class for which constant objects were created will have to be edited to declare constant member functions), mostly 1.2 code will be usable unchanged. You should *definitely* become familiar with the extensions of 2.0, however, so you don't inadvertantly do things the hard way without realizing that a better way is available in the new version. >Should we attempt to get the new version 2.0? Absolutely! Use of 1.2 should be viewed only as an interim step until you can get 2.0. Many of the grossities of 1.2 are eliminated or at least alleviated in 2.0. >Basically, 1) are the differences between the different current versions small >enough that code will be portable between them, and >2) will future changes to the language be small enough that we >will not have to change much of the code in the future? Answer to both questions: Yes, provided you keep your eyes open. In parti- cular, if you use g++, you *must* keep in mind what are nonstandard extensions in that environment because you won't find them anywhere else. John Carolan gave a pretty good talk on C++ programming for portability last February at Software Development '89; he might be willing to send you a set of the slides if you asked him (he's at Glockenspiel in Ireland; I don't have either the email or the regular mail address for them handy, but I'm sure someone does). -- Non-disclaimer: My boss and I always see eye-to-eye (every time I look in the mirror). ...!genrad!mrst!sdti!wmm
shap@delrey.sgi.com (Jonathan Shapiro) (10/25/89)
As much as I like Mike and respect what he has done, Gnu C++ isn't C++. Mike has elected, for various reasons, not to implement some features and to alter others. By and large, the things he has elected not to implement aren't a problem for most people. His handling of one or two things, however, creates interesting problems, notable when things get inlined. I would choose C++ 2.0 over G++. Jonathan S. Shapiro Synergistic Computing Associates