guthery@acw.UUCP (Scott Guthery) (10/15/89)
When thinking about using C++ for a real programming project consider the
following:
1) C++ is *NOT* a superset of C.
2) C++ has been under development for over 10 years and it
still isn't done.
3) An incompatible Release 2.0 just came out this year; existing
C++ projects must either be rewritten or use two different
incompatible compilers for the same langauge in their builds.
4) C++ experts are still arguing about how many features of C++
do work and should work.
5) Release 3.0 of C++ is under active development; still more
features will be added and existing featurres "improved"; no
guarantees about upward compatibility with 2.0 have been made.
6) C++ violates much of Wirth's advice about how programming languages
should be designed & developed; programming languages are not just
bags of tricks and features to be added to at will but this is how
C++ is being developed.
7) According to its author, C++ is designed for programs
measured in thousands of lines of code. The author goes
to say that if the program is measured in tens of thousands
of lines of code "mere progrmming language structuring
facilities can provide little relief." He's absolutely right.
8) There is no software management methodology for inheritance,
overloading, or persistent state among other C++ features.
9) The current version of the language has only a operational
definition; the final version has no definition at all.
10) There are no industrial grade development, debugging,
software management, configuration control or proram analysis
tools for C++.
There's no way a software project manager who cares about the quality,
deliverability, manageability, or long-term viability of his product
would commit a real software project to C++ in its current state. In
fact I've got to wonder about the software engineering skills of
someone who would even think about committing a project to an undefined
programming language. While you wait for Release 3.0, read "The Dark Side
of C++" in the Proceedings of ECOOP '88.
Cheers, Scott
+*+*+*+*+*+*+*+*+*+*+*+*+ Austin Code Works +*+*+*+*+*+*+*+*+*+*+*+*+*+*+**+*+
NET Domain: guthery@uunet.uu.net Post: 11100 Leafwood Lane
COM Domain: guthery@acw.com Austin, Texas 78750-3409 USA
US Domain: guthery@acw.austin.tx.us FAX: +1 (512) 258-1342
Path: {uunet}!acw!guthery Voice: +1 (512) 258-0785
Work: guthery@asc.slb.com TELEX: 446370 (austincodewrks)
Packet: N5MDE @ KB5PM EasyLink: 62752994
Fidonet: 1:382/12 Prodigy: KSWS89A
+*+*+*+*+*+*+*+*+*+*+*+*+* The Source of C +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+schmidt@zola.ics.uci.edu (Doug Schmidt) (10/16/89)
It would be nice if everything in life were easy...
In article <24.UUL1.3#913@acw.UUCP>, guthery@acw (Scott Guthery) writes:
++ When thinking about using C++ for a real programming project consider the
++ following:
++
++ 1) C++ is *NOT* a superset of C.
This is true, however it is not clear a priori that this situation is
an egregious oversight on the part of C++ designer. I suggest you
read the article `C++: as close as possible to C- but no closer' by
Stroustrup and Koenig, from the July/August 1989 issue of `The C++
Report.' This explains the rationale for various incompatibilities.
I program a great deal in both C and C++, and have not found the
`superset' issue a serious impediment in practice. In fact, even when
I write C code, I generally also compile it with a C++ compiler, since
the stronger type-checking catches many subtle errors that even ANSI C
compilers miss.
++ 2) C++ has been under development for over 10 years and it
++ still isn't done.
The same can be said for COBOL, FORTRAN, Ada, Modula 2/3, C, etc. C++
isn't Latin, i.e., it is not a *dead* language. In fact, I'm hard
pressed to name any significant/popular programming languages that
*haven't* undergone revision over the years. Can you?
++ 3) An incompatible Release 2.0 just came out this year; existing
++ C++ projects must either be rewritten or use two different
++ incompatible compilers for the same langauge in their builds.
Naturally, it is an *empirical* question whether existing C++ projects
must be re-written. For example, no one is holding a gun to C++
developers, forcing them to upgrade to 2.0.
More importantly, it is certainly possible to write useful C++ code
that relies upon the `core' language features, e.g. data abstraction
via classes. These features haven't changed much from release 1.2 to
2.0, though I'd probably be tempted to re-write old code simply
because 2.0 offers several more powerful abstraction mechanisms (e.g.,
class-specific new/delete operators, protected class members, multiple
inheritance, type-safe linkage, etc.).
++ 4) C++ experts are still arguing about how many features of C++
++ do work and should work.
Ditto for Ada, C, and any other popular language. Discussion and
dialogue are healthy. There's an apt cliche here:
`while you're green you're growing, once you're ripe you start to rot!'
There is no point trying to freeze the language in an incomplete
state. If you don't feel comfortable using it currently, simply wait
about 3 years, and try again!
++ 5) Release 3.0 of C++ is under active development; still more
++ features will be added and existing featurres "improved"; no
++ guarantees about upward compatibility with 2.0 have been made.
If you want guarantees, use Ada ;-) (ironically, however, the Ada 9x
committee is wrestling with many issues that C++ designers do, e.g.,
backward compatibility, avoiding `creeping featurism,' etc.).
++ 6) C++ violates much of Wirth's advice about how programming languages
++ should be designed & developed;
Wirth had many key insights regarding language design. However, he is
certainly not infalliable. For proof, ask yourself why Pascal has
failed to become a serious industry standard for programming
languages? The short answer is that it lacked many features that
proved necessary when writing `real' applications in an efficient and
portable manner. There is a thin line between parsimony and
inadequacy when designing programming languages...
++ programming languages are not just
++ bags of tricks and features to be added to at will but this is how
++ C++ is being developed.
Please provide concrete evidence for your claims, otherwise the
discussion becomes a raging polemic...
++ 7) According to its author, C++ is designed for programs
++ measured in thousands of lines of code. The author goes
++ to say that if the program is measured in tens of thousands
++ of lines of code "mere progrmming language structuring
++ facilities can provide little relief." He's absolutely right.
So, what's your solution here? Check out Fred Brook's `No Silver
Bullet' article. If you are looking for trivial panaceas to complex
problems you're not going to find it with either C++ or any other
programming language. The question here, however, is `does C++
provide better support for good software engineering principles
compared to its alternatives?' When the alternative is C (as often
occurs today), then I think the answer is affirmative.
++ 8) There is no software management methodology for inheritance,
++ overloading, or persistent state among other C++ features.
This is a failure of software engineering researchers, not necessarily
a failing of C++ designers.
++ 9) The current version of the language has only a operational
++ definition; the final version has no definition at all.
What exactly do you mean by this? It makes a good slogan, but is
rather content-free... Can you `prove' the final version has no
definition at all?!
++ 10) There are no industrial grade development, debugging,
++ software management, configuration control or proram analysis
++ tools for C++.
Sounds to me like there is a golden opportunity for some enterprising
developers to make a killing in the market. Luckily, it sounds like
you won't be among the competition ;-)
++ There's no way a software project manager who cares about the quality,
++ deliverability, manageability, or long-term viability of his product
++ would commit a real software project to C++ in its current state.
Is this a statement of opinion, or a statement of fact? If the latter
then I'm afraid there are many counter-examples.
++ fact I've got to wonder about the software engineering skills of
++ someone who would even think about committing a project to an undefined
++ programming language.
Great, please continue in search of the holy grail of programming languages.
If/when you find the perfect solution, please let us know!
Doug
--
Master Swordsman speak of humility; | schmidt@ics.uci.edu (ARPA)
Philosophers speak of truth; | office: (714) 856-4034
Saints and wisemen speak of the Tao of no doubt;
The moon, sun, and sea speaks for itself. -- Hiroshi Hamadakipp@warp.sgi.com (Kipp Hickman) (10/16/89)
We here at silicon graphics have been shipping real bona-fide low bugs products based on this ``unproduct worthy'' language C++. In fact, because C++ is such a power tool for development, we spend less time developing code and have more time to debug and improve performance and enrich the functionality of our software products. Also, because C++ is strongly typed, we waste no time on the stupid typo errors, but instead concentrate on the **real** problems - design, integration, performance. kipp hickman silicon graphics inc.
vaughan@mcc.com (Paul Vaughan) (10/16/89)
6) C++ violates much of Wirth's advice about how programming languages should be designed & developed; programming languages are not just bags of tricks and features to be added to at will but this is how C++ is being developed. While nearly everyone dabbles in proposing features for C++, I think Bjarne is doing an excellent job of identifying the real requirements and carefully assessing the consequences of the various proposals. While you might say that he adds features at will, I would add that his will is well considered and respectable. Also, in my use of the g++ succession of revisions, I find that updating programs to use the latest and greatest is not particularly difficult and that it usually uncovers latent bugs and inefficiencies. Changing my code is no problem, waiting for someone else to change theirs (libraries, for instance) can be. Compiler evolution is not such a bad thing. 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
jima@hplsla.HP.COM (Jim Adcock) (10/17/89)
Can anyone give any examples of someone who has been programming in C++ for more than a couple of months who would willing program in any other language, let alone any other dialect of C?
tom@elan.elan.com (Tom Smith) (10/17/89)
From article <1989Oct15.193756.6114@paris.ics.uci.edu>, by schmidt@zola.ics.uci.edu (Doug Schmidt): > In article <24.UUL1.3#913@acw.UUCP>, guthery@acw (Scott Guthery) writes: > ++ 3) An incompatible Release 2.0 just came out this year; existing > ++ C++ projects must either be rewritten or use two different > ++ incompatible compilers for the same langauge in their builds. > > Naturally, it is an *empirical* question whether existing C++ projects > must be re-written. For example, no one is holding a gun to C++ > developers, forcing them to upgrade to 2.0. Actually, this doesn't appear to be the case. We (software developers) have been hearing "Fixed in 2.0" for well over a year now. Bug fixes by AT&T and compiler vendors to 1.2 have come to a screaming halt. This would not ordinarily be cause for alarm, but 1.2 has been accurately labeled (by the author, I believe) a "research project", not a product. Developing a large-scale software project in an experimental language that has no support is not for the faint of heart (it's taken a couple of years off my expected lifespan). Most developers that I know view 2.x and GNU (to a large degree 2.0 compatible) as the only C++ version choices. Harken back to the flap over AT&T's pricing strategy announcement... Thomas Smith Elan Computer Group, Inc. tom@elan.com, ...!{ames, uunet, hplabs}!elan!tom
gary@dgcad.SV.DG.COM (Gary Bridgewater) (10/17/89)
My comments are in support of Doug, an additional rebuttal of Scott. I wanted Doug's comments as well since they are quite good. Sorry for the length. In article <1989Oct15.193756.6114@paris.ics.uci.edu> schmidt@zola.ics.uci.edu (Doug Schmidt) writes: >In article <24.UUL1.3#913@acw.UUCP>, guthery@acw (Scott Guthery) writes: >++ When thinking about using C++ for a real programming project consider the >++ following: >++ 1) C++ is *NOT* a superset of C. >This is true, however it is not clear a priori that this situation is >an egregious oversight on the part of C++ designer. > ... Agree but ... C is not a superset of anything. So what? This is a strawman argument. C++ is not a light blue Chevy truck. So what? C++ uses C syntax with extensions and restrictions. The extensions could confuse a C programmer who didn't know C++ but C could confuse a C programmer. There is a yearly contest based on that fact. So what? The extensions also provide in-line code which is a very powerful optimization tool (or will be when the bizarre length restrictions are removed). The restrictions bring C closer to what many of us wanted in C - strong type checking. >++ 2) C++ has been under development for over 10 years and it >++ still isn't done. >The same can be said for COBOL, FORTRAN, Ada, Modula 2/3, C, etc. C++ >isn't Latin, i.e., it is not a *dead* language. In fact, I'm hard >pressed to name any significant/popular programming languages that >*haven't* undergone revision over the years. Can you? Right - that means you have to keep up with the language just like you have to keep up with the O/S, the hardware, and the general stuff that makes the practice of software development more than a hobby. So what? >++ 3) An incompatible Release 2.0 just came out this year; existing >++ C++ projects must either be rewritten or use two different >++ incompatible compilers for the same langauge in their builds. >Naturally, it is an *empirical* question whether existing C++ projects >must be re-written. For example, no one is holding a gun to C++ >developers, forcing them to upgrade to 2.0. Hmmm. An ANSI release of C (almost) came out this year that made some horrors of the existing C incompatible or at least obsolete. Many people ran around yelling that the sky was falling. It wasn't. In this case, Doug, 1.2 and 2.0 are more incompatible than you say. Or so we have found. We may have used more of the "grey" features. But they don't link together due to mangler differences, in any case. You might get away with having disjoint versions of both. But, again - So what? We have a ton of code in 1.2. We are converting it to 2.0. We are commited to it because 1) it is better than C in many ways and 2) it is more portable than C across the platforms we want to run on. Our programs are so complex that we felt we had to have more power than C was going to give us. We could have made it portable (at a fair cost in performance) in C but it is doubtful if it would be working by now. >++ 4) C++ experts are still arguing about how many features of C++ >++ do work and should work. > >Ditto for Ada, C, and any other popular language. Discussion and >dialogue are healthy. There's an apt cliche here: > > `while you're green you're growing, once you're ripe you start to rot!' > >There is no point trying to freeze the language in an incomplete >state. If you don't feel comfortable using it currently, simply wait >about 3 years, and try again! I can't expand on that - agreed. >++ 5) Release 3.0 of C++ is under active development; still more >++ features will be added and existing featurres "improved"; no >++ guarantees about upward compatibility with 2.0 have been made. > >If you want guarantees, use Ada ;-) (ironically, however, the Ada 9x >committee is wrestling with many issues that C++ designers do, e.g., >backward compatibility, avoiding `creeping featurism,' etc.). Or pick a cpu and write assembler. It absolutely, positively won't change as long as you own that computer. I guarantee it. So what? >++ 6) C++ violates much of Wirth's advice about how programming languages >++ should be designed & developed; > >Wirth had many key insights regarding language design. However, he is >certainly not infalliable. For proof, ask yourself why Pascal has >failed to become a serious industry standard for programming >languages? The short answer is that it lacked many features that >proved necessary when writing `real' applications in an efficient and >portable manner. There is a thin line between parsimony and >inadequacy when designing programming languages... And our application was not to write a compiler. So Wirth's insight is interesting but inapplicable. We considered PASCAL - we all agreed it had many of the features we needed. But each platform had one or more relatively incompatible flavors of it. >++ programming languages are not just >++ bags of tricks and features to be added to at will but this is how >++ C++ is being developed. >Please provide concrete evidence for your claims, otherwise the >discussion becomes a raging polemic... One programmer's bag of tricks is another programmer's livelihood. X windows is just a bunch of tricks, and widgets and toolkits and looks-and-feels. RISC processors are just a bunch of tricks and gadgets. Unix and the unix commands are just a bunch of tricks and stuff glommed together. So what? >++ 7) According to its author, C++ is designed for programs >++ measured in thousands of lines of code. The author goes >++ to say that if the program is measured in tens of thousands >++ of lines of code "mere progrmming language structuring >++ facilities can provide little relief." He's absolutely right. > >So, what's your solution here? Check out Fred Brook's `No Silver >Bullet' article. If you are looking for trivial panaceas to complex >problems you're not going to find it with either C++ or any other >programming language. The question here, however, is `does C++ >provide better support for good software engineering principles >compared to its alternatives?' When the alternative is C (as often >occurs today), then I think the answer is affirmative. So did we. And we still do. And we have hundreds of thousands of lines. And it is hard to keep it together but 1) c++ forced us to define very concrete interfaces so we can let people work on different parts without fear of incompatibilities and 2) when you debug and finish an object then all instantiations of it instantly work. Note that 1&2 depend on very strict typechecking to guarantee they are true - the only place we have gotten in trouble is where we tried to fool the mechanism and we are paying. It is harder to write bad c++ than bad c - not impossible, just harder. >++ 8) There is no software management methodology for inheritance, >++ overloading, or persistent state among other C++ features. >This is a failure of software engineering researchers, not necessarily >a failing of C++ designers. It will come. >++ 9) The current version of the language has only a operational >++ definition; the final version has no definition at all. >What exactly do you mean by this? It makes a good slogan, but is >rather content-free... Can you `prove' the final version has no >definition at all?! Right. This is just a rehash of #1. >++ 10) There are no industrial grade development, debugging, >++ software management, configuration control or proram analysis >++ tools for C++. >Sounds to me like there is a golden opportunity for some enterprising >developers to make a killing in the market. Luckily, it sounds like >you won't be among the competition ;-) See # 8. Companies are working on it. This is definitely a problem for the 40-50 mips workstations of the '90s, in case any hardware type drags out that hoary old "what are you going to do with all that power" line. Just think about all the meta-information it will take to manage object descritption mods. >++ There's no way a software project manager who cares about the quality, >++ deliverability, manageability, or long-term viability of his product >++ would commit a real software project to C++ in its current state. >Is this a statement of opinion, or a statement of fact? If the latter >then I'm afraid there are many counter-examples. We have been using one for two years. We care a lot about quality, also time to market, maintainability, extensibility and transportability. >++ fact I've got to wonder about the software engineering skills of >++ someone who would even think about committing a project to an undefined >++ programming language. >Great, please continue in search of the holy grail of programming languages. >If/when you find the perfect solution, please let us know! We think they are a wonder too. And by the way, take a peek at InterViews for a good example of the power of c++ to put together a reasonable system in a short amount of time. Also note the size of the diffs to get it to 2.0. And it works! Where's your X toolkit? And why wasn't this posted in comp.religion? We are discussing the living world of c++ here, warts and all. Sure it needs to get better, faster, smarter, more tangible, etc., etc. but so do any number of other facets of software development. Why not join us and help fix the things you see that need fixing? -- Gary Bridgewater, Data General Corp., Sunnyvale Ca. gary@sv4.ceo.sv.dg.com or {amdahl,aeras,amdcad,mas1,matra3}!dgcad.SV.DG.COM!gary No good deed goes unpunished.
johnson@p.cs.uiuc.edu (10/17/89)
/* Written 12:02 pm Oct 16, 1989 by jima@hplsla.HP.COM in p.cs.uiuc.edu:comp.lang.c++ */ Can anyone give any examples of someone who has been programming in C++ for more than a couple of months who would willing program in any other language, let alone any other dialect of C? /* End of text from p.cs.uiuc.edu:comp.lang.c++ */ Let's not be silly. While C++ is a big improvement over C, it certainly is not the ultimate in programming languages. I've been using C++ for about 3 years and Smalltalk for about 4, and I much prefer Smalltalk. C++ has a number of advantages over Smalltalk, but these advantages are irrelevant to most of my programming, and it is much easier and more fun to program in Smalltalk. There have been a number of postings in this newsgroup from disgruntled ex-users. My guess is that most ex-users don't bother to read it. I read it because I still use C++, and I will continue to use it until something better comes along for low-level programming in the object-oriented style. Ralph Johnson
dfl@Think.COM (David Lively) (10/17/89)
In article <6590301@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
Can anyone give any examples of someone who has been programming in C++ for
more than a couple of months who would willing program in any other language,
let alone any other dialect of C?
I could name quite a few other (OO) languages which I'd rather use. But if
you want reasonable performance for *many* applications, C++ gives you
that, and beats the hell out of C. C++ was designed with efficiency as a
major goal, unlike most (all?) other OO languages. It accomplishes its
goals rather well, though substantial improvements are still needed. (e.g.
What's the plan for exception handling? I know it's on the horizon, but
how far off is that?)
*BIG* Caveat: I've never used another OO C, such as Objective C.
- Davidekrell@hector.UUCP (Eduardo Krell) (10/18/89)
In article <6590301@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >Can anyone give any examples of someone who has been programming in C++ for >more than a couple of months who would willing program in any other language, >let alone any other dialect of C? The answer is yes. If you promise anonymity and immunity from prosecution, send me e-mail and I'll give you more than one example. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
ark@alice.UUCP (Andrew Koenig) (10/18/89)
In article <6590301@hplsla.HP.COM>, jima@hplsla.HP.COM (Jim Adcock) writes: > Can anyone give any examples of someone who has been programming in C++ for > more than a couple of months who would willing program in any other language, > let alone any other dialect of C? Sure. I've programmed in C++ for several years now, and although most of my programming is indeed in C++, I still write shell scripts and programs in other languages, particularly Awk. I've written some programs in ML and would like to find the time to write more. I've written a lot of code in APL and still use it from time to time. I have my own little programming language called Snocone that's implemented by a Ratfor-ish preprocessor that translates into Snobol4. It's a good bit more powerful than Awk and is much better at string pattern matching than anything else I've seen, including C++ (until someone writes an appropriate class library). It only runs on machines that support Snobol4, though, which is why I use Awk instead of Snocone when I care about portability. I have only a passing acquaintance with Smalltalk, but what I've seen of it makes me sorry I have neither ready access to a machine that supports it nor time to explore it thoroughly. I've written considerable programs in Fortran, PL/I, Pascal, and several assembly languages, although not recently. I've also done a little programming in Lisp. I would use any of these languages again under the right circumstances. A programming language is a tool. No tool can be the best possible for every purpose. I can only imagine that there will continue to be good solid reasons for using any of a dozen or so languages in the appropriate context. C++ is an excellent language for a wide range of applications, but it's not perfect. If it were, those of us working on it would have to find something else to do. -- --Andrew Koenig ark@europa.att.com
nusbaum@meson.uucp (R. James Nusbaum) (10/18/89)
In article <6590301@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >Can anyone give any examples of someone who has been programming in C++ for >more than a couple of months who would willing program in any other language, >let alone any other dialect of C? Yes, me. Willing isn't quite the right word though. Different applications sometimes demand different solutions. I know you are all C++ fanatics here, but most of the features you like so well in C++ are done better in Eiffel, Smalltalk or Common Lisp with [Flavors, CommonLoops, CLOS, CommonObjects]. So if you really mean willing, well I'm not willing to program in anything but CommonLisp with Flavors, but that won't keep a paycheck coming in. :-) I am an object-oriented fanatic, but not necessarily a C++ fanatic. C++ is great, but it is a very immature product. I started programming with C++ right after it was first released to the academic community so I guess you could say I have used it a bit. When I started as leader of the project I'm working on now (~200,000 lines of code, 5-8 programmers, very high reliability and confidence level, multiple platforms) I looked closely at ALL available C++ products (Oregon, Oasys/Glockenspiel 1.2, AT&T 1.2, g++). None was suitable for commercial development. g++ had copyright/support problems. Oregon was way beta and full of bugs. Oasys/Glockenspiel failed my C++ validation suite. AT&T also had support problems. There were no symbolic debuggers (big problem) that worked on the actual C++ source. There was no decent documentation (everyone knows Bjarne's book is a little weak as a reference manual). All the compilers/translators were very young and I did not have the confidence in them that I do in a much more mature C product. Also the knowledge base for C++ and object-oriented stuff in general was and still is very weak. I feel I understand object-oriented programming very well, but I've been using it and doing research in it for five years. It can be very hard to teach and many people have a hard time understanding the concepts. So yes there were very valid reasons not to choose C++ for some projects. Many of those reasons are quickly going away which is great, but any software manager/group leader should carefully consider ALL the issues, not just the technical ones. By the way we used C with some home-built object oriented extensions. We will go to C++ when the computer vendors release supported binary versions with complete development environments (debuggers, profilers, etc.), which they are starting to do now. Jim Nusbaum Radiation Research Laboratory Loma Linda University Medical Center internet: nusbaum%proton.uucp@ucrmath.ucr.edu uucp: ...!ucrmath!proton!nusbaum
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (10/18/89)
In article <12294@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >In article <6590301@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: > >>Can anyone give any examples of someone who has been programming in C++ for >>more than a couple of months who would willing program in any other language, >>let alone any other dialect of C? > >The answer is yes. If you promise anonymity and immunity from prosecution, >send me e-mail and I'll give you more than one example. > My biggest concern with C++ is portability. Right now a variety of major environments are either unsupported or poorly supported; to wit, VMS, the IBM PC (Zortech C++ notwithstanding), the DECstation 3100, etc. I don't think C has any intrinsic advantages as a language or programming environment over C++ (although there are probably OTHER language subsets that are superior to their larger kin). I expect the portability issues to evaporate within 1-2 years, and even for cross-compilers shortly thereafter. C++ is flexible, complex and multifaceted, and is to C what the Z80 was to the 8080 -- in my opinion. It will inevitably replace C in the vast majority of areas where C is used now. It is nearly ideal as a systems-level programming language for the current generation of graphically-oriented workstations, and is suitable as a replacement for FORTRAN in mathematical applications (given tight code generation). It's the next wave, like it or not. (I like it but I wouldn't claim it as my own, if you know what I mean.) Aside from the issues of portability, my biggest concern with working in C++ is the horror of maintaining a large C++ project. I've found that generally C++ projects include much greater quantities of header files and are generally quite difficult to organize so that recompilation takes a sensible amount of time. What I WOULD like to see incorporated into the AT&T system is some method of handling incremental compilation and linking, and/or some kind of "project dictionary" in which the declarations can be stored in a precompiled form, in order to eliminate the 5000-line-header-wait problem. v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.
jima@hplsla.HP.COM (Jim Adcock) (10/18/89)
/ hplsla:comp.lang.c++ / dfl@Think.COM (David Lively) / 7:06 am Oct 17, 1989 / >In article <6590301@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: > >> Can anyone give any examples of someone who has been programming in C++ for >> more than a couple of months who would willing program in any other language >> let alone any other dialect of C? > >I could name quite a few other (OO) languages which I'd rather use. But if >you want reasonable performance for *many* applications, C++ gives you >that, and beats the hell out of C. C++ was designed with efficiency as a >major goal, unlike most (all?) other OO languages. It accomplishes its >goals rather well, though substantial improvements are still needed. (e.g. >What's the plan for exception handling? I know it's on the horizon, but >how far off is that?) > >*BIG* Caveat: I've never used another OO C, such as Objective C. I spent a couple years using Objective-C before switching to C++. I cannot imagine anyone switching in the other direction.
bright@Data-IO.COM (Walter Bright) (10/18/89)
In article <24.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes:
< 1) C++ is *NOT* a superset of C.
The differences are minor and easily corrected. In fact, you'll probably have
to do more work to convert K&R C to ANSI C than ANSI C to C++.
< 2) C++ has been under development for over 10 years and it
< still isn't done.
Name a language that's done (and is still being used!). Fortran has been
around since the dawn of time, and it keeps changing.
< 3) An incompatible Release 2.0 just came out this year; existing
< C++ projects must either be rewritten or use two different
< incompatible compilers for the same langauge in their builds.
Converting to 2.0 is rather trivial. Compiling 2.0 code under an old 1.2
compiler is not practical.
< 4) C++ experts are still arguing about how many features of C++
< do work and should work.
If you stick to the mainstream features, there isn't much debate about that.
< 5) Release 3.0 of C++ is under active development; still more
< features will be added and existing featurres "improved"; no
< guarantees about upward compatibility with 2.0 have been made.
See my response to 2).
< 9) The current version of the language has only a operational
< definition; the final version has no definition at all.
There is a spec for 2.0. Is there a "final" spec for any other language?
< 10) There are no industrial grade development, debugging,
< software management, configuration control or proram analysis
< tools for C++.
Development: Several quality C++ implementations exist.
Debugging: Ditto.
SW Managmnt: Who cares.
Config Cntrl: I use RCS. It works fine.
Prog Anal: I always thought that most software metric analysis progs
were pretty worthless.
<There's no way a software project manager who cares about the quality,
<deliverability, manageability, or long-term viability of his product
<would commit a real software project to C++ in its current state. In
<fact I've got to wonder about the software engineering skills of
<someone who would even think about committing a project to an undefined
<programming language.
It ain't that bad. Use of C++ has reached critical mass, which means that
the inertia of existing C++ code and use will 1) encourage the development
of new tools and refine existing ones 2) prevent arbitrary changes
to the language 3) provide continuity.jima@hplsla.HP.COM (Jim Adcock) (10/19/89)
Thanks for all the interesting and informative answers to my rhetorical flame-bait question. :-) Actually, I find it amazing how *few* [read: a couple] people who claim to have spent a non-trivial amount of time programming in C++ who would consider anything else. I have to admit even *I* program in bc, csh and awk *occasionally* I received a couple responses from people who'd rather use Smalltalk -- if it were faster. Others would rather use X,Y,Z--if it weren't for the realities of what it takes to make a commercial software product, etc, etc. Surprisingly, I didn't even receive any responses from people saying they had seriously checked out C++ [2.0] and given up to go back to C...... [If one *were* to give up on C++ *which* C would one go back to?] :-)
fox@allegra.att.com (David Fox) (10/19/89)
jima> Surprisingly, I didn't even receive any responses from people saying jima> they had seriously checked out C++ [2.0] and given up to go back to jima> C...... They may not be reading this... -david
randolph@ektools.UUCP (Gary L. Randolph) (10/19/89)
In article <2169@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >In article <24.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes: Several points deleted. >< 10) There are no industrial grade development, debugging, software management, configuration control or program analysis tools for C++. >Development: Several quality C++ implementations exist. Probably true. >Debugging: Ditto. I work with a Sun workstation using a beta version of Sun's C++ 2.0. dbx and dbxtool don't work on the beta version but I am looking forward to seeing how well they work in the final product. At least I wont be looking at mangled names! >SW Managmnt: Who cares. My management cares. This is a biggie. As a strong proponent of C++ within my company, I would like to show management that C++ provides an improved way of constructing software that makes it easier to manage! Isn't that the raison detre of C++? Schema management is going to be important to those maintaining C++ code. OOA and OOD are of a stronger concern to many than is the language issue. I can convince people that C++ is wonderful in many ways, but that puts the cart before the horse since analysis and design issues are still somewhat nebulous. Where do I send people to learn a *proven* OORA/OOD methodology? >Config Cntrl: I use RCS. It works fine. Good, where can I get info on this? >Prog Anal: I always thought that most software metric analysis progs > were pretty worthless. Another biggie. Though many (not all) metrics are worthless (IMHO), we can't give up on measuring productivity accross languages. I feel that C++ would fair well in terms of productivity (especially when class libs are abundant) and would like whatever metrics are being used to be able to show that fact. Gary Randolph Eastman Kodak
des@orenda.amara.uucp (Dave Steinhoff) (10/19/89)
Jim Adcock writes: >I spent a couple years using Objective-C before switching to C++. I cannot >imagine anyone switching in the other direction. Why not? Does anyone else have experience with both languages who would care to contrast them? -- ------------------------------------------------------------------- Dave Steinhoff Applied Dynamics International des@amara.UUCP 3800 Stone School Rd. ...uunet!amara!des Ann Arbor, Mi 48108 -------------------------------------(313)973-1300-----------------
jeffa@hpmwtd.HP.COM (Jeff Aguilera) (10/20/89)
C is dead. Long live C++.
jos@cs.vu.nl (10/20/89)
jima@hplsla.HP.COM (Jim Adcock) writes: >Can anyone give any examples of someone who has been programming in C++ for >more than a couple of months who would willing program in any other language, >let alone any other dialect of C? Yes, me. I am a romantic person. For a long time I have been undertaking the quest for the ideal language. Realism tells me that it probably doesn't exist. As a result of this quest I started to use C++, about four years ago. I have used C++ for over three years. At both institutes I worked during this time, I ported and installed the AT&T translator (release E .. 1.2). I have used C++ for OOP as well as just a better C (with argument and typechecking). IMHO, for both projects, C++ proved to be far more useful then C. Conclusion: C++ is `better' then C. Wrong conclusions: C is bad/C++ is good. In my quest for the ideal language, I kept looking for alternatives. Last year I started using Eiffel, which comes a lot closer to the ideal language. I will go on using it, until something `better' shows up. Jos Warmer jos@cs.vu.nl ...uunet!mcvax!cs.vu.nl!jos P.S. Everything depends on your personal definition of the "ideal language". ========================================================================= Opinions are nice to talk about: everyone is always right.
bright@Data-IO.COM (Walter Bright) (10/20/89)
>In article <2169@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >>In article <24.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes: <<Config Cntrl: I use RCS. It works fine. <Good, where can I get info on this? RCS (Revision Control Software) is a pretty much standard unix utility to do configuration control on ascii text files. Thus, it works on C Fortran, C++, etc. with equal facility. Similar software is named SCCS. It's available in various forms for most platforms, including DOS (from Polytron).
jima@hplsla.HP.COM (Jim Adcock) (10/21/89)
>At least I wont be looking at mangled names!
I presume everbody working with 2.0 compilers has found the c++filt
demangler tool? For example, one of my favorite tricks to help figure out
what's going on is to do:
CC -O -S someclass.c
sed "s/_//" < someclass.s | c++filt > someclass.S
-- where someclass.S is assembly code with demangled names. I have to do
the sed "s/_//" stuff because my C compiler adds a prefix "_" to names
when generating assembly. Nowadays to figure out what a C++ compiler is
doing I look at the generated assembly. The generated "C" code is hopeless
gobbledygook.mce@tc.fluke.COM (Brian McElhinney) (10/21/89)
In article <2169@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >Prog Anal: I always thought that most software metric analysis progs > were pretty worthless. Have you ever looked at the "McCabe Cyclomatic Complexity Metric"? I've found, for C code at least, that it does a very good job at finding error-prone portions of code. There is also a very convincing article in the Hewlett-Packard Journal (April 1989). Basically, the McCabe metric turns code into a graph, where each line of code is a node (the edges are the control flow between nodes). Applying some math from graph theory, you get a small integer number that "measures" complexity. From experience, a number greater than 10 is usually worth investigating/testing/redesigning/whatever. Unfortunately, I'm sure the McCabe metric is not going to be directly useful for C++ code. It is limited to the complexity of a single function. C++ gets complicated in the inter-relationships of methods, and of course, of classes. Methods are typically not very complex. Still, the same approach should be useful for "measuring" the complexity of a class or set of classes. Brian McElhinney "If always without desire, one can observe marvels; if mce@tc.fluke.com always desireous, one sees merest traces." Lao-Tzu
fischer@iesd.auc.dk (Lars P. Fischer) (10/21/89)
In article <24.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes: > 7) According to its author, C++ is designed for programs > measured in thousands of lines of code. The author goes > to say that if the program is measured in tens of thousands > of lines of code "mere progrmming language structuring > facilities can provide little relief." He's absolutely right. A large piece of software like TeX has inherent complexity that cannot be reduced below a certain level of difficulty, although each individual part is fairly simple by itself. -- D. E. Knuth, The TeXbook That's life, my friend. "No Silver Bullets", ya know. Writing large pieces of software is difficult. So is building a bridge. Do you think that's a failure of C++? /Lars -- Copyright 1989 Lars Fischer; you can redistribute only if your recipients can. Lars Fischer, fischer@iesd.auc.dk, {...}!mcvax!iesd!fischer Department of Computer Science, University of Aalborg, DENMARK. Radical social changes begins on the street! So if your looking for some action... cut the crap and get out there. -- Joe Strummer
wmm@sdti.com (William M. Miller) (10/23/89)
In article <24.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes: > 1) C++ is *NOT* a superset of C. In absolute terms, that is correct. However, many (most?) well-written C programs will compile under C++ with only minor changes like the addition of function prototypes and casts. These changes are improvements to the program, IMHO. > 2) C++ has been under development for over 10 years and it > still isn't done. Until X3J11 voted out the pANS, C was still ``not done'' (e.g., the flap over whether noalias was going to be part of the language or not), and C is substantially older than C++. (And there's still no guarantee that there won't be more evolution after the Standard is approved.) > 3) An incompatible Release 2.0 just came out this year; existing > C++ projects must either be rewritten or use two different > incompatible compilers for the same langauge in their builds. The incompatibilities aren't very severe, and ``conversion'' should be trivial to nonexistent (except for fixing *warnings* about the future disappearance of certain features like assignment to ``this.'' > 4) C++ experts are still arguing about how many features of C++ > do work and should work. There are many such discussions for C and Ada as well, and those languages have been through the considerable refinement of the standardization process already! Except for dark, cobwebby corners, most of C++ is well- understood and agreed upon. And, since C++ is now entering the standards arena, most of those corners should be swept and illuminated in the near future as well. > 6) C++ violates much of Wirth's advice about how programming languages > should be designed & developed; programming languages are not just > bags of tricks and features to be added to at will but this is how > C++ is being developed. Wirth is not the ultimate font of wisdom on such matters. It is at least arguable that a language designer who, on the basis of the principle of parsimony, provides an ODD function but not EVEN, is somewhat out of touch with real-world programmers. C++ features overlap and duplicate sometimes, but it is clearly a real-world language of real-world utility. The history of the language shows clearly, furthermore, that Bjarne has done an excellent job of resisting the calls from users to throw in features that just solve their specific problem and has instead developed broadly-useful additions that integrate very well with the existing language. There is much to be said for the idea of getting real-world experience with the language and then deciding what needs to be done to improve it instead of pontificating from one's ivory tower in academia. > 8) There is no software management methodology for inheritance, > overloading, or persistent state among other C++ features. I'd be very interested in proposals to rectify those omissions. > 9) The current version of the language has only a operational > definition; the final version has no definition at all. Perhaps you're unaware of the reference manual shipping with the 2.0 translator. While it's not perfect, it is better than anything that existed in print for the C language until the publication of Harbison & Steele. (My feeling is that K&R and Stroustrup's book provide roughly the same level of documentation of their respective languages.) That doesn't address the ``final version'' issue, true, but a good portion of that definition has been or is about to be published (parameterized types and exception handling), and X3J16 should be sufficient impetus to do the rest. >I've got to wonder about the software engineering skills of >someone who would even think about committing a project to an undefined >programming language. Well, I would, too. C++ as it stands now does not fall into that category. The language is quite well defined, and based on past performance, I have every reason for confidence that future versions of the language will invalidate little, if any, of the current definition. >While you wait for Release 3.0, read "The Dark Side >of C++" in the Proceedings of ECOOP '88. I've read it; I certainly wouldn't claim that the language was perfect, but obviously I was less persuaded by that paper than you. > > Cheers, Scott > >+*+*+*+*+*+*+*+*+*+*+*+*+ Austin Code Works +*+*+*+*+*+*+*+*+*+*+*+*+*+*+**+*+ And to think, I just bought some stuff from you folks! :-) -- Non-disclaimer: My boss and I always see eye-to-eye (every time I look in the mirror). wmm@sdti.sdti.com
bright@Data-IO.COM (Walter Bright) (10/24/89)
In article <11859@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: >In article <2169@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: <<Prog Anal: I always thought that most software metric analysis progs << were pretty worthless. <Have you ever looked at the "McCabe Cyclomatic Complexity Metric"? I've <found, for C code at least, that it does a very good job at finding <error-prone portions of code. <Applying some math from graph theory, you get a small <integer number that "measures" complexity. From experience, a number greater <than 10 is usually worth investigating/testing/redesigning/whatever. I've never heard of it. However, what I've found works best is: 1. Run a fresh listing. 2. Acquire some performance-enhancing drugs (coffee, Coke, Jolt Cola all work) from the local all-night 7-11. 3. Tune the radio to Brain Pain (Sunday nights on 90.3 for Washingtonians). Those poor souls outside of 90.3's EMI range might make do with Metal Church, Sanctuary, Queensryche, Slayer or Judas Priest. Close the windows so you don't frighten the neighbor's dog. 4. Get a red pen. 5. Simply *read* the listing. It's truly amazing the number of problems/bugs you find this way. It's also surprising how many programmers *never* read their code unless their looking for a bug or are enhancing it. 6. If you find a section that is incomprehensible, but you know what its supposed to do, X it out with the pen and rewrite it from scratch. 7. Be brave. Good code has been rebuilt from the ground up at least 3 times. 8. We doan' need no steenkin' program to discover complicated code. :-)
henry@utzoo.uucp (Henry Spencer) (10/25/89)
In article <2176@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: > ... >4. Get a red pen. >5. Simply *read* the listing. It's truly amazing the number of problems/bugs > you find this way... Just to add some reinforcement to this: if you're not in a big hurry to get the code out the door, let it sit for a week without looking at it before you do this. This doubles the amazement. I did this repeatedly before shipping my freely-redistributable regular- expression code. The code was much improved as a result. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
richard@pantor.UUCP (Richard Sargent) (10/25/89)
jeffa@hpmwtd.HP.COM (Jeff Aguilera) wrote in message <1520002@hpmwjaa.HP.COM>:
> C is dead. Long live C++.
Don't be silly. C has a very long life ahead of it, too. After all,
just look at FORTRAN (1956!). I'm sure Algol proponents said much
the same about FORTRAN.
Now, some will claim that C++ has stronger typing than C. This is
a valid claim, provided you've been saddled with a K&R implementation.
I don't know how things are in the real world, but here in PC-land,
most C compilers I have worked with have tracked the developing
ANSI C standard. This means I have had strong typing and prototypes
for nigh on two years now.
I wonder when Unix C compilers will get updated?
Richard Sargent Internet: richard@pantor.UUCP
Systems Analyst UUCP: uunet!pantor!richardschwartz@dinl.uucp (Michael Schwartz) (10/27/89)
> I wonder when Unix C compilers will be updated.
A number of such compilers are available, but are subject to
Gresham's law of software:
Free software will drive out good software.
--
-----------------------
schwartz%looney@mmc.com "Expect everything ...
mschwartz@mmc.com and the unexpected never happens."
ncar!dinl!schwartz --the phantom tollbooth
DISCLAIMER: The opinions expressesed are not necessarily those of my
employer or myself.