comp.lang.ada
 help / color / mirror / Atom feed
From: agate!howland.reston.ans.net!darwin.sura.net!seas.gwu.edu!mfeldman@ucbvax .Berkeley.EDU  (Michael Feldman)
Subject: Re: Ada and C++: A request for comparison/contrast/relative benifits
Date: 8 Aug 93 00:46:08 GMT	[thread overview]
Message-ID: <1993Aug8.004608.1337@seas.gwu.edu> (raw)

In article <241b49$b44@truffula.fp.trw.com> erwin@trwacs.fp.trw.com (Harry Erwi
n) writes:
>The query is for a comparison/contrast/relative benefits assessment of C++
>and Ada. I'll introduce C as a third comparison point.
I'm going to try to keep this as factual as I know how; our experiences
are all different and your mileage may vary.
>
>1. Development cost: If C development costs "1" and assembly language
>costs "3", the costs for both C++ and Ada (in my experience) run between 1
>and 3. The reason C++ costs so much is that I'm a simulation programmer,
>and I find myself getting into the arcane details of allocators,
>iterators, etc. Ada costs more than C because it takes more work to write
>the same code (about 2x). Of course, the maintenance costs of Ada are much
>less...
No problem here. Also the testing costs should be lower (see below):
>
>2. Performance. A C SLOC converts into about 5 machine language
>instructions. C++ is about the same...except for allocators, copy
>operators, destruction operators, etc., which tend to be invisible to the
>programmer, but not to the performance engineer. Ada SLOCs convert to
>about 10 machine language instructions (2xC), but you don't get into the
>arcane object creation/copying/destrution stuff. Experience suggests C++
>code can be very crufty if the programmer doesn't keep this arcane lore in
>mind.
I can't speak for C++, but many quite reasonable benchmarks have shown
that, for reasonably comparable algorithms and optimizations, the time
and space performance of Ada programs is very near to, sometimes better
than, C. I think the 2xC figure is not unreasonable, but represents
a specific compiler/algorithm pair. And a lot of the extra Ada instructions
often come from run-time checking code not present in the C code.

Those checks can, of course, be suppressed if the programmer wishes,
and this will make the algorithms exactly comparable; the resulting
code should then be comparable in size and speed. Why would it not be?

Also, using Ada _well_ can result in better-optimized code.
As an example, consider making a copy of a 2-d array. In C you would
write this in a nested loop. (See below for comments on tricks.)
In Ada, you'd simply write 

A := B;

and let the compiler use block moves to carry out the copying. Any
reasonable Ada optimizer should (I'm not saying _does_) do this.
If A and B are of known size, the compiler can generate a few big moves
to copy the data, and skip all the loop overhead.

In C, you could use some sort of trickery - as
is sometimes done with assembler, or EQUIVALENCEs in Fortran - to cut
down on the number of iterations, thus on the loop overhead. But in Ada,
the structures are such that - if one uses them intelligently -
the compiler can optimize what you were hand-optimizing in other
languages. I think people underestimate the power of predefined
assignment (and equality test) for optimization. Or maybe the compilers
aren't handling it well, but that's for another discussion.
>
>3. Functionality/Power. C and Ada are similar. C++ introduces
>object-oriented programming, complete with run-time resolution of
>linkages. The only kitchen sink missing from C++ is call by name (in
>Simula and Smalltalk, you can make a function call and have the parameters
>copied in at evaluation time (repetitively if necessary)).  This reduces
>the power of the language, but not a lot.
Things like the universal copying, coupled with much stronger compile-
time checking and run-time checking/exception propagation, give Ada expressive 
power closer to that of C++ than to that of C. In C++ you are gaining OOP 
at the cost of genericity, exceptions, and parallelism; in Ada it's the 
other way around. For many applications this is an equivalent trade, in most 
of the analyses I've seen. 

C++ is adding generic templates and exceptions; Ada is adding single
inheritance and dynamic dispatching. This leaves Ada9X missing
multiple inheritance, which is controversial at best, with some C++
fans saying it's a solution in search of a problem. C++ is left without
parallelism, at least as far as I know. This makes them pretty equivalent,
both in their current and their evolving forms.
>
>I guess in conclusion, Ada costs more and is easier to maintain. C++ has
>more power, but is harder to code and maintain, and has arcane features. C
>costs less, has less features, costs more to maintain, but is easier to
>use in real-time applications.
Your last statement is quite hard to follow. Ada's real strength is in
real-time applications, as evidenced by the fact that
- ALL new jetliners are using Ada in their avionics;
- ALL new air-traffic-control systems (as far as I know) are being done
  in Ada, from US and Canada to Vietnam, with Europe and Africa in between;
- a good deal of the European high-speed rail system is being done in Ada,
  especially R/T stuff like train control/communication.

Undoubtedly C is easier for small-scale PC-based realtime systems or
simulators. But harder to test, debug, and maintain. I'll post a new
story about French Rail, which is moving over to Ada from a large
C-based system for train control. The main reason is Ada's much easier
testing and maintenance.

Let's keep going with facts; flames to /dev/null.

Mike Feldman

             reply	other threads:[~1993-08-08  0:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-08-08  0:46 Michael Feldman [this message]
  -- strict thread matches above, loose matches on Subject: below --
1993-08-13  8:56 Ada and C++: A request for comparison/contrast/relative benifits H.K. Pang
1993-08-11  4:49 Robert Dewar
1993-08-10  2:43 cis.ohio-state.edu!math.ohio-state.edu!darwin.sura.net!seas.gwu.edu!mfeld
1993-08-09 22:06 Robert Dewar
1993-08-09 18:53 Peter Juhl
1993-08-09 13:45 agate!spool.mu.edu!darwin.sura.net!source.asset.com!theeke
1993-08-09  5:25 Robert Dewar
1993-08-08 21:55 agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!d
1993-08-08 17:47 Bjarne Stroustrup
1993-08-07 22:42 cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!news.ecn
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox