alan@hal.larc.nasa.gov (alan dare) (06/12/91)
Netlanders,
A short time ago I put a request out for information on c++ vs
Ada. I was hoping for several responses from people on both sides of the
fence that were working on graphics applications. As my primary application
is graphics. What did I receive? I received more requests to post the results
than I received mail from people using c++ or Ada. I received only two
messages from people using c++ in a graphics application and none from
anyone using Ada. There were several messages from general users of c++
and only a few from Ada users. A kind soul FAX'ed me a document "A comparison
of Experiences with the Maintenance of Object-Oriented Systems: Ada vs. C++".
I didn't try to post a summary of the article (it's to big). The comments
below were sent to me. I don't claim any responsibility for them. I don't
currently use c++ or Ada. The comments are provided as a request from many
people. Please don't use this posting to start a language war.
The first post went to the following news groups:
comp.sys.sgi
comp.graphics
alt.graphics
comp.lang.ada
comp.lang.c++
The comments below were edited only to reduce size, not content.
**************************************************
*** Graphics *************************************
**************************************************
o I use C++ for graphics work. We considered ADA.
Both have great pluses and a lot of minuses.
Mostly the minuses are finding existing graphics packages
which are compatible. They are rare with C++ and non-existent
with ADA to my knowledge.
o Ada has lots of features totally irrelevant to graphics
which cost something in compile time even on a compiler that
produces efficient code. It has no particular features to
reccommend it for graphics particularly over any of the common
block-structured languages.
**************************************************
*** PRO ADA Comments *****************************
**************************************************
o The Ada MIL-SPEC and validation suites do a
lot to insure a consistent interpretation of the
language across platforms and vendors. No such
validation or "frozen" specification exists for
C++. This causes lost time and less portability.
o Ada's Packages and Generic Packages are a
lot easier to design for than C++ classes.
o Ada has better support for embedded systems'
work than C++. C++'s OO mechanisms
(particurlarly dynamic binding) exact a performance
penalty that will not be acceptable for some
hard real-time systems. This will be less
important in the future, as hardware gets
faster and applications get more complicated
(thus requiring the complexity-management
mechanisms offered by languages like C++).
Ada 9X will probably suffer similar performance
penalties on the same kinds of mechanisms.
**************************************************
*** CON ADA Comments *****************************
**************************************************
o The language is too big for the few benefits over C++ that
it features.
o Ada is a "weaker" language than C++ in expressing
OO concepts (e.g. inheritance, polymorphism).
Packages, Generic Packages and Ada's overloaded
operators aren't enough. Ada 9X will supposedly
deal with these issues, but it will be at least a decade
before the Ada 9X environment is truly widely
available at a reasonable cost.
o ADA compilers tend to cost real money.
o ADA suffers from having way too many features -- probably
an artifact of the design-by-committee process. It's such a
huge language that a programmer may never fully "learn" it.
o Converting code to ADA from anything is a problem.
o ADA still tends to be slow, though that problem is slowly
going away.
o Ada is only object-based (it has no inheritance), while
C++ _is_ object-oriented.
**************************************************
*** PRO C++ Comments *****************************
**************************************************
o The dynamic binding, polymorphism and inheritance mechanisms
are *extremely* powerful, and very useful in graphical
applications. Future enhancements including parameterized
types (== Ada "Generic Packages") and exceptions
(== Ada exceptions) are going to be equally powerful.
o After extensive reading and personal evaluation, I came to the
conclusion the ADA implementions are far worse than the C
implementations (I use the stuff from GNU, don't see how anyone
can write better software).
o C++ compilers are cheap -- the GNU family is free, and runs
on a number of different architectures. You can get the source
code so that you can fix it if it's broken.
o C++ seems to be a reasonably clean design; the features tend to
be orthogonal and complete. A competent programmer can probably
"learn" C++ pretty well in a month.
o Converting code from C to C++ isn't a big problem. (And with
some of the Fortran-to-C translators that are publicly available,
the Fortran->C->C++ path, while a bit of a pain, isn't
completely daunting.)
o C++ runs just about as fast as C, i.e. it's plenty fast enough
to write things like volume renderers.
**************************************************
*** CON C++ Comments *****************************
**************************************************
o The tools for working with it maybe not as mature as ada tools.
o C++ is hard to master.
o C++ has reasonable OO mechanisms, but they
are difficult to learn, and more difficult to use
effectively. This is partially due to the low
quality of the documentation, which is quickly
changing.
**************************************************
*** GENERAL Comments *****************************
**************************************************
o There are a lot more Ada people out there, at
the moment, than C++ people. There will probably
be a lot more C++ people in the future than Ada
people, simply because the language is more
accessable to more people (Gnu C++ is free, for
example; "Turbo C++" costs ~$60; AT&T is
very generous in licensing to Universities).
o There will probably be a lot more C++ compilers
available on a lot more platforms than Ada
compilers in the future (the costs of validation
are high; reuse of AT&T code or GNU code
is cheap).
I would like to thank the following for responding to my post :
baker@csl.dl.nec.com
blbates@aero36.larc.nasa
brendan@illyria.wpd.sgi.com
fmhv@inesc.inesc.pt
jansm@cih.hcuge.ch
jdt@voodoo.boeing.com
jls@netcom.com
jshumate@logdis1.wr.aflc.af.mil
leisner.henr801c@xerox.com
richard@elroy.Jpl.Nasa.Gov
rsk@gynko.circ.upenn.edu
uselton@nas.nasa.gov
--
*********************************************************************
Alan Dare | Internet : alan@hal.larc.nasa.gov
NASA Langley Research Center | pmartz@undies.dsd.es.com (Paul Martz) (06/13/91)
In article <1991Jun12.164741.412@news.larc.nasa.gov>, alan@hal.larc.nasa.gov (alan dare) writes: > > > Netlanders, > > A short time ago I put a request out for information on c++ vs > Ada. [...] The comments > below were sent to me. I don't claim any responsibility for them. I don't > currently use c++ or Ada. The comments are provided as a request from many > people. Please don't use this posting to start a language war. > > [...] > > o I use C++ for graphics work. We considered ADA. > Both have great pluses and a lot of minuses. > Mostly the minuses are finding existing graphics packages > which are compatible. They are rare with C++ and non-existent > with ADA to my knowledge. Just for the record, Evans & Sutherland sells an Ada binding to PHIGS for use with our ESV graphics workstation. > [...] > > ********************************************************************* > Alan Dare | Internet : alan@hal.larc.nasa.gov > NASA Langley Research Center | -- -paul pmartz@dsd.es.com Evans & Sutherland
jls@netcom.COM (Jim Showalter) (06/13/91)
>o I use C++ for graphics work. We considered ADA. > Both have great pluses and a lot of minuses. > Mostly the minuses are finding existing graphics packages > which are compatible. They are rare with C++ and non-existent > with ADA to my knowledge. Ada bindings to X windows (including a nearly pure-Ada version donated by Rational to MIT) are available. There is at least one firm I know of that does nothing EXCEPT write X windows graphics applications in Ada. Incidentally, Ada is a name, not an acronym. So, like Pascal, it is capitalized, not uppercased like FORTRAN. >o Ada has lots of features totally irrelevant to graphics > which cost something in compile time even on a compiler that > produces efficient code. Any language has features totally irrelevant to graphics, unless that language is specifically a graphics language (which C++ is not). It is unclear to me how an Ada feature that is not used can "cost something in compile time"--could someone elaborate? >o The language is too big for the few benefits over C++ that > it features. What does "too big" mean, actually? I hear this bandied about all the time, but when I press someone to precisely explain what features of Ada they think are superfluous, they stammer about um, well, tasking or some such--and yet, if you ask someone who USES tasking, they regard it as indispensable. I am reminded of the line in "Amadeus" when the king tells Mozart that his work has "too many notes", to which Mozart replies "Well, sire, which notes exactly would you have me remove?". Really, factually, Ada has approximately the same number of keywords, control structures, and fundamental concepts as C++ or any other software engineering oriented language. Certainly it is bigger than C, but so is C++--that's the whole POINT. >o ADA compilers tend to cost real money. Indeed. And they tend to provide real functionality: they work, have few bugs, have excellent support backing them up, are validated, and scale to projects of significant size and complexity. You get what you pay for. >o ADA suffers from having way too many features -- probably > an artifact of the design-by-committee process. It's such a > huge language that a programmer may never fully "learn" it. Again--which notes would you have me remove, sire? As for the design by committee accusation, two points: 1) it wasn't a committee, really--it was actually a handful of clever people led by a particularly clever Frenchman named Ichbiah; the language was subject to extensive international review, but that doesn't constitute a committee, 2) a Lexus is a car designed by a committee; it is also one of the finest cars ever designed: perhaps the issue is not the existence of a committee but, rather, the QUALITY of the committee that should be taken into account. As for learning the entire language--why should one HAVE to? If you don't need concurrency control, then by all means ignore tasking. If you don't need fixed point types, then by all means ignore them. It is really quite simple to learn a very powerful and flexible subset of the language. >o Converting code to ADA from anything is a problem. Huh? >o ADA still tends to be slow, though that problem is slowly > going away. As with the "too many features" shibboleth, this common myth doesn't hold up under even rudimentary analysis of the facts. There are compilers available for a number of targets that produce code at least as dense and efficient as C/C++ compilers for the same target. >o C++ compilers are cheap -- the GNU family is free, and runs > on a number of different architectures. You can get the source > code so that you can fix it if it's broken. You get what you pay for. Personally, I'd much prefer to buy a validated compiler with the number of bugs approaching zero than use a free compiler so shot full of bugs the source code is provided to me to patch around problems that SHOULD have been taken care of by the vendor. >o C++ seems to be a reasonably clean design; the features tend to > be orthogonal and complete. A competent programmer can probably > "learn" C++ pretty well in a month. Funny, about every 9th posting to comp.object concerns one or another person's complaints about C++ being a kludgy, idiosyncratic, hard-to-learn language. And, in my experience, it takes more like 6 months to a year for a programmer to REALLY learn how to write well in C++ (yes, one can hack together executing code fairly quickly, but to get from there to where one can design competently in the language requires a lot of practice). >o Converting code from C to C++ isn't a big problem. (And with > some of the Fortran-to-C translators that are publicly available, > the Fortran->C->C++ path, while a bit of a pain, isn't > completely daunting.) The C++ code that results from a double translation effort as described is ugly in the fullest sense of the word. You don't gain much by translating legacy code written in an archaic language into a different language--the REAL win is in translating to a new DESIGN and then coding that new design in a more modern language. This requires human effort and ingenuity, and is NOT something that can be automated (at least not with current state of the art), but the eventual payoff is considerable. Automated translation of a bad design written in a bad language into a bad design written in a better language is a perfect example of the GIGO principle in action. Show me a translator that will convert legacy FORTRAN into a well-abstracted class hierarchy in C++ and I'll start to be impressed. Until then, spare me. >o The tools for working with it maybe not as mature as ada tools. Indeed. >o C++ is hard to master. Indeed. Note that this contradicts the claim made earlier that C++ is easy to learn. >o C++ has reasonable OO mechanisms, but they > are difficult to learn, and more difficult to use > effectively. This is partially due to the low > quality of the documentation, which is quickly > changing. It is even more due to the fact that such mechanisms, despite their billing, are actually quite tricky to master conceptually. The number of people I've encountered who'd I trust to actually design a class hierarchy of any significant complexity I can count on one hand. Sadly, hacker culture being what it is, EVERYBODY is going to want to do try their hand at building such things, and most are going to fail miserably. Not everybody is an architect, so why pretend that they are? -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
pierson@encore.com (Dan L. Pierson) (06/13/91)
Regarding c++ vs ada results; alan@hal.larc.nasa.gov (alan dare) adds: (quoting someone else; don't blame him :-)) > o Ada has better support for embedded systems' > work than C++. C++'s OO mechanisms > (particurlarly dynamic binding) exact a performance > penalty that will not be acceptable for some > hard real-time systems. This assertion contains a common misconception about dynamic binding _for languages which support both dynamic and static binding_. Such languages include C++, Common Lisp/CLOS and the current proposal for Ada 9X. The misconception is that the performance of a dynamically dispatched (bound) function call should be compared to that of a normal function call. It should not; it should be compared to the performance of a normal function call PLUS a case statement. If you don't need the case statement you should have used a statically bound call*. A good implementation of dynamic dispatch for any of these languages can be faster than static call plus case. There are several existence proofs for C++ and Common Lisp/CLOS, but I don't have the citations handy. *Of course, a poor programmer can overuse dynamic binding with greater ease than explicit case statements. IMHO, all of the cited languages have enough such options already available that this isn't a big issue when weighed against the advantages in software construction and reuse provided by dynamic binding. -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@encore.com
paul@u02.svl.cdc.com (Paul Kohlmiller) (06/14/91)
jls@netcom.COM (Jim Showalter) writes: >As with the "too many features" shibboleth, this common myth doesn't >hold up under even rudimentary analysis of the facts. There are >compilers available for a number of targets that produce code at >least as dense and efficient as C/C++ compilers for the same target. Jim, Could you specify one or more machines that have an available ADA compiler that generates code that is as efficient as a C compiler for the same machine? thnx Paul Kohlmiller CDC standard disclaimers -- // Paul H. Kohlmiller // "Cybers, Macs and Mips" // // Control Data Corporation // Internet: paul@robin.svl.cdc.com // // All comments are strictly // America Online: Paul CDC // // my own. // Compuserve: 71170,2064 //
pelakh@convex.com (Boris Pelakh) (06/14/91)
In article <34128@shamash.cdc.com> Paul Kohlmiller writes: > Could you specify one or more machines that have an available ADA compiler >that generates code that is as efficient as a C compiler for the same machine? The Ada compiler on the Convex C series performs scalar optimization as well as vectorization and parallelization, offering comparable speed to out FORTRAN and C compilers. -- Boris Pelakh "My hair like Jesus wore it, Development Software Test Hallelujah, I adore it." pelakh@convex.com -- Hair
jls@netcom.COM (Jim Showalter) (06/14/91)
>Jim, > Could you specify one or more machines that have an available ADA compiler >that generates code that is as efficient as a C compiler for the same machine? Sure, but we have to qualify the answer somewhat in order for it to be meaningful. Since C has no inherent support for multi-thread execution, there is no valid way to compare the efficiency of Ada tasking to that of C, since only Ada has it. So tasking is out. Since C has no inherent support for genericity, there is no valid way to compare the efficiency of Ada generic code to that of C, since only Ada has it. So generics are out. Similar arguments can be advanced for fixed point types, exceptions, and numerous other features present in Ada and missing from C. I suppose one could try to mimic the missing features in C, thereby greatly increasing the size of the resulting C executable (e.g. homebrew semaphores for rudimentary tasking, macro expansion for generics, etc), but then we're arguing over the efficiency of the workaround in C, not the speed of the compilers directly. In fact, it seems to me that the only realistic comparison one can make is between Ada that doesn't use any of the features missing from C, which leaves us pretty much with scalar, floating point, array, and record manipulation by subprograms/functions. And, to make the comparison even closer, we must remember to disable all constraint checking by the Ada compiler, since C sees nothing wrong with pointers walking off into hyperspace with the result that the machine tries to execute data... Subject to all of these caveats, it is really pretty easy to find an Ada compiler that rivals a C compiler on many targets, since there isn't really much that the Ada compiler needs to DO. I suggest you investigate the compilers available from Rational, DEC, Alsys, Telesoft, Tartan, and Softech for starters. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
larryc@porter.jpl.nasa.gov (Larry Carroll) (06/14/91)
In article <deleted> paul@u02.svl.cdc.com (Paul Kohlmiller) writes: >Could you specify one or more machines that have an available Ada compiler >that generates code that is as efficient as a C compiler for the same machine? Ask instead what vendor supplies this. There are probably several; one of the better ones come from Tartan, who also supply compilers for other languages. The founders of Tartan included several of the people from Carnegie-Mellon who pioneered optimization technology in the late 70's & early 80's, so that shouldn't be surprising. Further, Ada compilers can produce tighter & faster code than many older languages because it contains constructs that give the compiler information it needs to do optimization. This includes ranges, as in type tiny_int is integer range 0..1; whose data can be fit into one bit (if size were important) or byte or word for some machines (where speed might depend on putting single-bit data on a byte or word boundary).
emery@Dr_No.mitre.org (David Emery) (06/14/91)
Paul Kohlmiller says > Could you specify one or more machines that have an available ADA compiler >that generates code that is as efficient as a C compiler for the same machine? First try to construct an equivalent C program to an Ada program using strong typing, constraint checks, etc. Then you have something to compare apples to apples... dave emery
erwin@trwacs.UUCP (Harry Erwin) (06/14/91)
paul@u02.svl.cdc.com (Paul Kohlmiller) writes: >jls@netcom.COM (Jim Showalter) writes: >>As with the "too many features" shibboleth, this common myth doesn't >>hold up under even rudimentary analysis of the facts. There are >>compilers available for a number of targets that produce code at >>least as dense and efficient as C/C++ compilers for the same target. >Jim, > Could you specify one or more machines that have an available ADA compiler >that generates code that is as efficient as a C compiler for the same machine? >thnx >Paul Kohlmiller Our experience is that an Ada compiler generates almost twice as many machine instructions per executable statement as a C compiler. This has nothing to do with the underlying efficiency of the compiler and everything to do with the bells and whistles associated with the language. Harry Erwin erwin@trwacs.fp.trw.com -- Harry Erwin Internet: erwin@trwacs.fp.trw.com
nelson@sun.soe.clarkson.edu (Russ Nelson) (06/16/91)
In article <1991Jun12.201740.16463@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >o ADA still tends to be slow, though that problem is slowly > going away. As with the "too many features" shibboleth, this common myth doesn't hold up under even rudimentary analysis of the facts. There are compilers available for a number of targets that produce code at least as dense and efficient as C/C++ compilers for the same target. >o C++ compilers are cheap -- the GNU family is free, and runs > on a number of different architectures. You can get the source > code so that you can fix it if it's broken. You get what you pay for. Personally, I'd much prefer to buy a validated compiler with the number of bugs approaching zero than use a free compiler so shot full of bugs the source code is provided to me to patch around problems that SHOULD have been taken care of by the vendor. Why is "ada is slow" a myth, but "GCC is shot full of bugs" is not? Certainly if you're an expert on GCC's bugs, you could name one of them. It's been my experience that the vendors of compilers *never* share their bug list with customers. For GCC, you just have to tune into gnu.gcc.bug. -- --russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker. I am leaving the employ of Clarkson as of June 30. Hopefully this email address will remain. If it doesn't, use nelson@gnu.ai.mit.edu.
sef@kithrup.COM (Sean Eric Fagan) (06/16/91)
In article <1991Jun12.201740.16463@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >Indeed. And they tend to provide real functionality: they work, >have few bugs, have excellent support backing them up, are validated, >and scale to projects of significant size and complexity. You get >what you pay for. And >You get what you pay for. Personally, I'd much prefer to buy a validated >compiler with the number of bugs approaching zero than use a free compiler >so shot full of bugs the source code is provided to me to patch around >problems that SHOULD have been taken care of by the vendor. 1. gcc (and g++) are among the best and least buggy compilers (especially considering their ages) that I've ever seen. 2. Real world experience: a certain software company, affiliated with my previous employer through various means, has a C compiler. We got their C compiler and resold it for our system. The compiler had more bugs than I can count on both hands (in binary, that is 8-)); when I found a bug, and asked "did you fix this?" I would almost always get a response of, "maybe, but we're working with this later version [which wasn't released until two years later, mind you] so we can't help you." My ex-housemate, working for yet another company (as a customer of said software company) eventually gave up on their software support and sent me dozens of email messages asking a) is this a real bug, and, if so, b) how can I work around it? 3. I have encountered far fewer bugs in gdb than, say, sdb. Yet sdb is a "validated debugger," for which one pays lots of money. Yep. Useful things, those proprietary development tools. >>o C++ is hard to master. >Indeed. Note that this contradicts the claim made earlier that C++ is >easy to learn. You are truly showing your foolishness here. Most people out of grade school realize there is a difference between "learning" something and "mastering" it. I guess you're just special, aren't you? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.