* Re: "Subtract C, add Ada" [not found] <3etund$hnr@miranda.gmrc.gecm.com> @ 1995-01-12 9:56 ` Erik Svensson [not found] ` <3f0n6b$qnp@theopolis.orl.mmc.com> ` (2 subsequent siblings) 3 siblings, 0 replies; 37+ messages in thread From: Erik Svensson @ 1995-01-12 9:56 UTC (permalink / raw) > 3. uninitialised pointer access > 4. pointer references to local variables in defunct procedures >The syntax of Ada removes or reduces errors like 1. and 2. but does >not really address 3. or 4. (admitedly, 4. is an unnatural practice in >Ada and would be pretty rare anyway). Since Ada inititalizes (Sp?) all access variables to Null 3, would seem to be handled as well, or at least easily handled. ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <3f0n6b$qnp@theopolis.orl.mmc.com>]
[parent not found: <3f3cq3$4tu@gnat.cs.nyu.edu>]
* Re: uninitialzed variables [not found] ` <3f3cq3$4tu@gnat.cs.nyu.edu> @ 1995-01-12 14:25 ` Richard Kenner 0 siblings, 0 replies; 37+ messages in thread From: Richard Kenner @ 1995-01-12 14:25 UTC (permalink / raw) In article <3f3cq3$4tu@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes: >T.E.D. says that all Ada compilers he knows detect uninitialized variables. >Well not quite, since this problem is of course recursively undecidable. It >is true that a compiler can detect some obvious cases of uninitialized >variables, that's not in GNAT yet, but is on our list of nice things to add. Actually, it is in GNAT since this is done by the GCC optimizer. Specify the flag -Wuninitialized along with -O or -O2 and it will warn about variables that appear to be uninitialized. As Robert points out, this must be approximate since the problem is undecidable. In practice, it tends to have more false positives than false negatives. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Subtract C, add Ada" [not found] <3etund$hnr@miranda.gmrc.gecm.com> 1995-01-12 9:56 ` "Subtract C, add Ada" Erik Svensson [not found] ` <3f0n6b$qnp@theopolis.orl.mmc.com> @ 1995-01-12 14:44 ` Norman H. Cohen 1995-01-13 1:51 ` David O'Brien 3 siblings, 0 replies; 37+ messages in thread From: Norman H. Cohen @ 1995-01-12 14:44 UTC (permalink / raw) In article <3etund$hnr@miranda.gmrc.gecm.com>, bill@valiant (R.A.L Williams) writes: |> My experience of writing software and running software projects in C |> highlights four common low-level C errors: |> 1. = instead of == and vice versa |> 2. spurious ; after for(...) or while(...) |> 3. uninitialised pointer access |> 4. pointer references to local variables in defunct procedures |> The syntax of Ada removes or reduces errors like 1. and 2. but does |> not really address 3. or 4. (admitedly, 4. is an unnatural practice in |> Ada and would be pretty rare anyway). No, Ada helps to eliminate all four kinds of errors. #3: In Ada, all pointers are initialized by default to null. An attempt to dereference a null pointer IMMEDIATELY raises Constraint_Error, so these errors are generally discovered during testing. (The only way they could fail to be discovered is if the testing failed to exercise the path along which the dereference is reached without a prior assignment of a nonnull value.) In C such an error could remain undiscovered even if the tests exercise the relevant path. The arbitrary contents of the uninitialized pointer might happen not to generate an invalid memory reference; or the error could occur sporadically and irreproducibly, but manifest itself only indirectly, much later in the execution of the program, because of some datum clobbered by assignment to the variable "pointed to" by an uninitialized pointer. Then the error might never be properly attributed to the dereference of an uninitialized pointer. #4: In Ada 83, access values point only to dynamically allocated variables, not to declared variables, so the issue does not arise. In Ada 95, access values can pointed to variables declared aliased, but a pointer to a local variable of a subprogram can only belong to an access type that is itself declared inside the subprogram, so the pointer cannot outlive the variable to which it was pointing. |> The really strong point about Ada, especially where large teams, or |> inexperienced coders, are involved is that it strongly encourages |> the separation of SPECIFICATION from IMPLEMENTATION, and provides |> a language enforced formalisation of the mechanism. Never mind the |> commonly expressed rationale behind this, ie. information hiding: |> forcing the interfaces between components to be *designed* before |> attempting to write the implementation, and then encouraging (because |> of the sheer hassle of not doing it) some sort of formal mechanism |> if the interfaces have to be changed has got to be the main factor in |> the success of a project. I agree. I also agree with you that it is not hard for programmers who understand the Ada philosophy to use C in a disciplined way to simulate Ada packages. However, violations of the discipline are not easily recognized or enforced. (The discipline involves, among other things, remembering to override the inexcusable C default that functions are extern rather than static; and always #include'ing a header file with the declarations of a file's external functions both in the file defining those functions--to ensure consistency as the file is modified--and in all files calling such functions.) But don't underestimate the power of the stupid little errors--the ones that occur and persist in C programs, but never occur or are eliminated immediately in Ada programs--to slow a project down or even cause its failure. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Subtract C, add Ada" [not found] <3etund$hnr@miranda.gmrc.gecm.com> ` (2 preceding siblings ...) 1995-01-12 14:44 ` "Subtract C, add Ada" Norman H. Cohen @ 1995-01-13 1:51 ` David O'Brien 1995-01-13 12:38 ` Laurent Gasser ` (3 more replies) 3 siblings, 4 replies; 37+ messages in thread From: David O'Brien @ 1995-01-13 1:51 UTC (permalink / raw) R.A.L Williams (bill@valiant) wrote: : My experience of writing software and running software projects in C : highlights four common low-level C errors: : 1. = instead of == and vice versa I have to wonder. What if C defined the logical equals operator to be "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal, Modula-x, etc? Would this error still exist??? Quickly thinking about it, I feel that I write a lot more assignment statements than local statements, couldn't I be in the habit of typing ":=" and thus accidently type that when I meant logical comparison? Since that would still be a perfectly valid, conforming C program, the compiler is not required to give any warnings (just like current practice). Thus, I would still have the same logic error in my program. Chances of happening??? Any bodies guess. So is the problem really one of symbol choice, or program semantics? : 2. spurious ; after for(...) or while(...) This is one area I *really* like about Ada. However, I feel there is a much more common programming error (occurs in Pascal too): for (...) first_action(); second_action(); The indenting implies that "second_action()" should be part of the the loop body. But it isn't. :-)) So many times I've seen this in industry. Every new programmer I work with I try to drill into their head's "*always* use braces with your if, while, for statements, even when you have only one thing in your loop body. For one day a maintainer will need to add that second thing, and indent like the above -- forgetting to add the braces." Many will not listen thinking they know better. Tisk, tisk, tisk. Usually it doesn't take long for them to get bitten and remember. Same for Pascal. I really don't understand why most languages are designed the Pascal/C way rather than the Ada way. Especially since it removes the common ambiguity of nested if statements. -- David O'Brien (dobrien@seas.gwu.edu) ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-13 1:51 ` David O'Brien @ 1995-01-13 12:38 ` Laurent Gasser 1995-01-13 20:53 ` John DiCamillo ` (2 more replies) 1995-01-14 10:37 ` "Subtract C, add Ada" Keith Thompson ` (2 subsequent siblings) 3 siblings, 3 replies; 37+ messages in thread From: Laurent Gasser @ 1995-01-13 12:38 UTC (permalink / raw) In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes: |> R.A.L Williams (bill@valiant) wrote: |> : My experience of writing software and running software projects in C |> : highlights four common low-level C errors: |> : 1. = instead of == and vice versa |> |> I have to wonder. What if C defined the logical equals operator to be |> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal, |> Modula-x, etc? Would this error still exist??? The problem is in the language definition, not in the choic of symbols. C is one of the rare language I use to allow having an assignment after the if statement. All other languages only allow for a boolean test. I never saw a good reason for allowing this. -- Laurent Gasser (gasser@dma.epfl.ch) Computers do not solve problems, they execute solutions. I know very few ideas worth dying for, none is worth killing. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-13 12:38 ` Laurent Gasser @ 1995-01-13 20:53 ` John DiCamillo [not found] ` <3f8fnf$c8p@gamma.ois.com> [not found] ` <3fa11q$sdh@gnat.cs.nyu.edu> 1995-01-14 0:24 ` David O'Brien 1995-01-20 4:43 ` Samuel Mize 2 siblings, 2 replies; 37+ messages in thread From: John DiCamillo @ 1995-01-13 20:53 UTC (permalink / raw) gasser@masg1.epfl.ch (Laurent Gasser) writes: >In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes: >|> R.A.L Williams (bill@valiant) wrote: >|> : My experience of writing software and running software projects in C >|> : highlights four common low-level C errors: >|> : 1. = instead of == and vice versa >|> >|> I have to wonder. What if C defined the logical equals operator to be >|> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal, >|> Modula-x, etc? Would this error still exist??? >The problem is in the language definition, not in the choic of symbols. >C is one of the rare language I use to allow having an assignment after >the if statement. All other languages only allow for a boolean test. >I never saw a good reason for allowing this. Huh? It falls naturally out of two other C rules: 1) an assignment is an expression whose value is equal to that of the thing being assigned, 2) any expression that evaluates to integer 0 is false, all other expressions are true. C would have required a special restriction to prevent assignment in an if-test. (Note that assignment in a loop-test is a useful and common idiom in C.) That said, if this error is anyone's biggest concern about developing software in C, then that person has not really tried to develop software in C. All lan- guages have warts, even Ada. -- ciao, milo ================================================================ John DiCamillo Pinin' for the fjords? milod@netcom.com What kind of talk is that? ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <3f8fnf$c8p@gamma.ois.com>]
* Re: "Subtract C, add Ada" [not found] ` <3f8fnf$c8p@gamma.ois.com> @ 1995-01-16 11:02 ` Matt Kennel [not found] ` <milodD2IFpG.329@netcom.com> 1 sibling, 0 replies; 37+ messages in thread From: Matt Kennel @ 1995-01-16 11:02 UTC (permalink / raw) R. William Beckwith (beckwb@ois.com) wrote: : John DiCamillo (milod@netcom.com) wrote: : : That said, if this error is anyone's biggest concern : : about developing software in C, then that person has : : not really tried to develop software in C. All lan- : : guages have warts, even Ada. : Some languages' warts are really malignant tumors. ;-) So, all languages have warts, but only in bad ones do they metastasize? ;-) -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego -*** AD: Archive for nonlinear dynamics papers & programs: FTP to -*** lyapunov.ucsd.edu, username "anonymous". ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <milodD2IFpG.329@netcom.com>]
* Re: "Subtract C, add Ada" [not found] ` <milodD2IFpG.329@netcom.com> @ 1995-01-17 21:39 ` R. William Beckwith 0 siblings, 0 replies; 37+ messages in thread From: R. William Beckwith @ 1995-01-17 21:39 UTC (permalink / raw) John DiCamillo (milod@netcom.com) wrote: : beckwb@ois.com (R. William Beckwith) writes: : >John DiCamillo (milod@netcom.com) wrote: : >: That said, if this error is anyone's biggest concern : >: about developing software in C, then that person has : >: not really tried to develop software in C. All lan- : >: guages have warts, even Ada. : >Some languages' warts are really malignant tumors. ;-) : Did you have something useful to follow that up with? No, but I'll make the attempt since you're interested. : Do you disagree with either of the sentences you were : responding to? Do you feel that I am misrepresenting : the relative quality of the two languages in question? Not really and yes. I agree everything has warts. It has been my experience that while Ada's occasional warts can be annoying, C's occasional warts can be deadly. ... Bill ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <3fa11q$sdh@gnat.cs.nyu.edu>]
* Re: "Subtract C, add Ada" [not found] ` <3fa11q$sdh@gnat.cs.nyu.edu> @ 1995-01-16 20:20 ` David Moore 0 siblings, 0 replies; 37+ messages in thread From: David Moore @ 1995-01-16 20:20 UTC (permalink / raw) dewar@cs.nyu.edu (Robert Dewar) writes: >For another example of UNIFY/CONFUSE, does Algol-68 confuse or unify the >concepts of pointers and variables. My vote would be for UNIFY. Algol-68 clarified many things that were implicit in other languages. For example, Algol 68 made it clear that in the expression: A:=A; The type of A on the left has one more "ref" than the A on the right. I have found that being cavalier about ref's is a good way to get in a horrible mess when writing a compiler or debugger. Hence, I believe anyone who intends to be a language implementor or lawyer should be familiar with Algol 68. Unfortunately, it also introduced W-Grammars which I find almost impossible to manipulate. They belong to level 3, or perhaps 4 in the complexity heirarchy of formalisms: Level 1 Formalism. You can push instances (eg simple sentences in the language) through the formalism in your head. Level 2 Formalism. You can push through instances on a piece of foolscap while sitting at your desk. Level 3 Formalism. You have to get up and clean off the whiteboard before starting. Level 4 Formalism. You and your colleagues have to go into a conference room and clean off the whiteboards. You first have to argue that the phrase "Do not erase" has a scope no larger than the phrase itself. Fortunately, there is also an "informal" report on Algol 68 which is very readable. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-13 12:38 ` Laurent Gasser 1995-01-13 20:53 ` John DiCamillo @ 1995-01-14 0:24 ` David O'Brien 1995-01-20 4:43 ` Samuel Mize 2 siblings, 0 replies; 37+ messages in thread From: David O'Brien @ 1995-01-14 0:24 UTC (permalink / raw) Laurent Gasser (gasser@masg1.epfl.ch) wrote: : In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes: : |> R.A.L Williams (bill@valiant) wrote: : |> : My experience of writing software and running software projects in C : |> : highlights four common low-level C errors: : |> : 1. = instead of == and vice versa : |> : |> I have to wonder. What if C defined the logical equals operator to be : |> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal, : |> Modula-x, etc? Would this error still exist??? : The problem is in the language definition, not in the choice of symbols. : C is one of the rare language I use to allow having an assignment after : the if statement. All other languages only allow for a boolean test. Yep, that's my point. The argument of character choice really isn't what is at the essence of the problem. Rather it is the language definition. : I never saw a good reason for allowing this. Simply the paradigm of C that *every* statement has a value. And C has no special logical values. So C has "values are values" akin to Ford's offering of the Model-T, "any colour you want, as long as it's black". I'm guessing Ritchie did this for the same reason as Henry Ford - to simply things. Which gave us the situation we have. In most languages the grammar would be: conditional_statement ::= if <logical_expression> then Which in C becomes: conditional_statement ::= if ( <expression> ) <statement> and thus ``<expression>'' must include ``<lvalue> = <expression>''. -- David O'Brien (dobrien@seas.gwu.edu) ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-13 12:38 ` Laurent Gasser 1995-01-13 20:53 ` John DiCamillo 1995-01-14 0:24 ` David O'Brien @ 1995-01-20 4:43 ` Samuel Mize 1995-01-21 20:28 ` David O'Brien 2 siblings, 1 reply; 37+ messages in thread From: Samuel Mize @ 1995-01-20 4:43 UTC (permalink / raw) In article <3f5s92$3id@info.epfl.ch>, Laurent Gasser <gasser@masg1.epfl.ch> wrote: > >The problem is in the language definition, not in the choic of symbols. >C is one of the rare language I use to allow having an assignment after >the if statement. All other languages only allow for a boolean test. > >I never saw a good reason for allowing this. > It's a question of who optimizes your code. In the 60s, when C was developed, compilers *couldn't* optimize code, so the programmer had to. Many apparently-bizarre C capabilities are there to support optimization level -1 (programmer does the optimizations). Consider the common C idiom to copy a null-terminated array, usually a string [syntax may not be quite right]: while (*a++=*b++); Recall that C considers 0 false, a null character is integer 0, and an assignment returns what was assigned. This loop condition copies the character at address b to address a, increments both, and exits when a null was copied. There is no statement inside the loop. This is more efficient, with a non-optimizing compiler, than while (*a) { *a = *b; a=a+1; b=b+1}; /*or whatever is right syntax*/ because * The operator ++ increments the value of while it's still in a register. The second code reads a from memory to do the character assign, reads it again to increment it. * ++ can use the assembler's increment instruction. a=a+1 could not. * Using the assignment as the loop expression indirectly directs the compiler to keep the result of the assignment in a register for reuse in the expression, instead of writing it to memory, then reading it. Thus, with a lot of man-hours, expertise and skull-sweat, someone using a basic C compiler can come within an order of magnitude of the efficiency of someone using a half-good optimizing Ada compiler. Often. Of course, if you only *read* the code, and don't *run* it, it looks like the C is more optimized, because you can *see* the optimizations. With Ada you write less-optimized-looking code, and trust the compiler. (But verify.) >-- >Laurent Gasser (gasser@dma.epfl.ch) >Computers do not solve problems, they execute solutions. > >I know very few ideas worth dying for, none is worth killing. I dunno, I've killed quite a few ideas in my time :-) Sam Mize - smize@starbase.neosoft.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-20 4:43 ` Samuel Mize @ 1995-01-21 20:28 ` David O'Brien 1995-01-22 21:12 ` Robert Dewar ` (4 more replies) 0 siblings, 5 replies; 37+ messages in thread From: David O'Brien @ 1995-01-21 20:28 UTC (permalink / raw) In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote: : It's a question of who optimizes your code. In the 60s, : when C was developed, compilers *couldn't* optimize code, : so the programmer had to. Many apparently-bizarre C : capabilities are there to support optimization level -1 : (programmer does the optimizations). C was designed in the 70's. The earliest reference I could find to it is the cc(1) UNIX 3rd Edition man page dated 3/15/72 from "A Quarter Century of Unix". The language from which C developed, B, was created in 1970. And the only published document on the B language, "CSTR #8 - The Programming Language B", is dated Jan 1973. BCPL, which B came from, is from 1969. So, I think that "compilers *couldn't* optimize code" may be an over generalization. Is this _really_ the case for 1970's compiler technology? : Consider the common C idiom to copy a null-terminated : array, usually a string [syntax may not be quite right]: : while (*a++=*b++); I am curious about programming culture. Notice that when someone writes something in C they feel they have to remove all white space. When they write in Ada they put in plenty and use [very] long names for every thing. Why is that??? No wonder people say C is hard to read. : This is more efficient, with a non-optimizing compiler, than : while (*a) : { *a = *b; a=a+1; b=b+1}; /*or whatever is right syntax*/ : because : * The operator ++ increments the value of while it's still : in a register. The second code reads a from memory to : do the character assign, reads it again to increment it. You are making a *major* assumption about the CPU this is running on. On many smaller uP's there isn't that many registers. : * ++ can use the assembler's increment instruction. a=a+1 : could not. Since adding 1 to variable is so common place, it is trivial to add this type of optimization (even in your parser). : * Using the assignment as the loop expression indirectly : directs the compiler to keep the result of the assignment : in a register for reuse in the expression, instead : of writing it to memory, then reading it. Again, you really are thinking with a preconceived notion of your hardware. -- David O'Brien (dobrien@sea.gwu.edu) ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-21 20:28 ` David O'Brien @ 1995-01-22 21:12 ` Robert Dewar 1995-01-23 18:35 ` Norman H. Cohen ` (3 subsequent siblings) 4 siblings, 0 replies; 37+ messages in thread From: Robert Dewar @ 1995-01-22 21:12 UTC (permalink / raw) "compilers couldn't optimize code" what is meant here is "C compilers didn't optimize code", and this was partly a matter of philosophy, the idea that C compilers should be simple and do what you say, and NOT rely on optimization. Optimization technology was well developed even in the late 60's. Fortran-2 for the 7094 did a remarkably good job of optimizing loops. Fortran-H was contemporary with early C compilers, and was very aggressive in optimizing typical Fortran code. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-21 20:28 ` David O'Brien 1995-01-22 21:12 ` Robert Dewar @ 1995-01-23 18:35 ` Norman H. Cohen 1995-01-23 19:18 ` John Cosby - The Coz ` (2 subsequent siblings) 4 siblings, 0 replies; 37+ messages in thread From: Norman H. Cohen @ 1995-01-23 18:35 UTC (permalink / raw) In article <3frqpg$re5@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes: |> In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote: |> : It's a question of who optimizes your code. In the 60s, |> : when C was developed, compilers *couldn't* optimize code, |> : so the programmer had to. Many apparently-bizarre C |> : capabilities are there to support optimization level -1 |> : (programmer does the optimizations). ... |> : Consider the common C idiom to copy a null-terminated |> : array, usually a string [syntax may not be quite right]: |> |> : while (*a++=*b++); |> |> I am curious about programming culture. Notice that when someone writes |> something in C they feel they have to remove all white space. When they |> write in Ada they put in plenty and use [very] long names for every |> thing. Why is that??? No wonder people say C is hard to read. It's because the primitive compilers of the 1970's were incapable of optimizing away the whitespace. ;-) -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-21 20:28 ` David O'Brien 1995-01-22 21:12 ` Robert Dewar 1995-01-23 18:35 ` Norman H. Cohen @ 1995-01-23 19:18 ` John Cosby - The Coz 1995-01-24 14:11 ` Samuel Mize [not found] ` <3g655n$q5k@theopolis.orl.mmc.com> 4 siblings, 0 replies; 37+ messages in thread From: John Cosby - The Coz @ 1995-01-23 19:18 UTC (permalink / raw) David O'Brien (dobrien@seas.gwu.edu) wrote: : In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote: : : It's a question of who optimizes your code. In the 60s, : : when C was developed, compilers *couldn't* optimize code, : : so the programmer had to. Many apparently-bizarre C : : capabilities are there to support optimization level -1 : : (programmer does the optimizations). : C was designed in the 70's. The earliest reference I could find to it : is the cc(1) UNIX 3rd Edition man page dated 3/15/72 from "A Quarter : Century of Unix". The language from which C developed, B, was created : in 1970. And the only published document on the B language, "CSTR #8 - : The Programming Language B", is dated Jan 1973. BCPL, which B came : from, is from 1969. The July-August 1978 edition of "The Bell System Technical Journal" contains an article by Ritchie, Johnson, Lesk, and Kernughan entitled "The C Programming Language." In this article they state that B was written in 1970 by Ken Thompson "for the first UNIX system on the PDP-11." They go on to discuss how the introduction of types was a major departure from BCPL and B and mention in passing that C was created "circa 1972." An interesting article, which discusses many of the issues debated during the evolution of Ada into Ada95 from a much "earlier" point of view. Fun to see how far we've come. John ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-21 20:28 ` David O'Brien ` (2 preceding siblings ...) 1995-01-23 19:18 ` John Cosby - The Coz @ 1995-01-24 14:11 ` Samuel Mize [not found] ` <3g655n$q5k@theopolis.orl.mmc.com> 4 siblings, 0 replies; 37+ messages in thread From: Samuel Mize @ 1995-01-24 14:11 UTC (permalink / raw) In article <3frqpg$re5@cronkite.seas.gwu.edu>, David O'Brien <dobrien@seas.gwu.edu> wrote: ... >C was designed in the 70's. ... >So, I think that "compilers *couldn't* optimize code" may be an over >generalization. My apologies for a loose statement. I meant to address the observed beliefs of people who feel that they can write more-efficient code in C. Generally, they hand-write code-level optimizations; they can see it, so they believe in it. They don't expect the compiler to optimize much. Some of them don't *want* the compiler to optimize; they're using side effects and "slick tricks" to save three instructions per hundred. Of course, a good optimizer would do far better for them, but they can't see that unless they meter their program, optimize it, and meter it again. Why bother with what when they *know* that it's more efficient code... Of course, the source code doesn't run. The object code runs. ... >You are making a *major* assumption ... >Again, you really are thinking with ... Your entire post is right, except for attributing these beliefs to *me*. I was unclear. These are beliefs that C programmers have stated to me, as to why C is "more efficient" than Ada. Of course, if a programmer is manually optimizing, he/she must have assumptions about, and a model of, the machine on which the code will run. Sometimes, these will be wrong. Another argument for machine optimization, which Ada better supports. >-- David O'Brien (dobrien@sea.gwu.edu) Yours in agreement, Sam Mize - smize@starbase.neosoft.com ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <3g655n$q5k@theopolis.orl.mmc.com>]
* Ada vs. C [not found] ` <3g655n$q5k@theopolis.orl.mmc.com> @ 1995-01-30 15:33 ` Martijn Bak 0 siblings, 0 replies; 37+ messages in thread From: Martijn Bak @ 1995-01-30 15:33 UTC (permalink / raw) >It all falls out of the design of the language. Constructs like "+=" >provide no benifit other than to save typing within a single >statement. Take the statement: > > Principle = Principle + (Interest * Time) > >The "+=" operator is MADE for this statement, but its ONLY benifit is >to save me 11 characters in my source file. Nope, in general this is _not_ true! The statements expr1 += expr2; and expr1 = expr1 + expr2; are _not_ the same. In the former, expr1 is evaluated only once, in the latter expr1 is evaluated twice. This is not only a matter of execution speed. It is especially important if expr1 has side-effects. There is also a conceptual benefit for the += (if expr1 is very complex). Compare a[i->j(q,b)] = a[i->j(q,b)] + 2; and a[i->j(q,b)] += 2; In the latter case, neither the writer nor the reader of this code need to check whether a[i->j(q,b)] and a[i->j(q,b)] realy are the same. Yep, I _am_ a C programmer. -- -- Martijn Bak -- AND Software -- Westersingel 108, 3015 LD Rotterdam -- -- tel: +31-10-4367100 -- fax: +31-10-4367110 -- email: martijn@and.nl -- ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Subtract C, add Ada" 1995-01-13 1:51 ` David O'Brien 1995-01-13 12:38 ` Laurent Gasser @ 1995-01-14 10:37 ` Keith Thompson [not found] ` <3fcjgt$b0v@cronkite.seas.gwu.edu> [not found] ` <D2It0r.4rp@inmet.camb.inmet.com> [not found] ` <3g9nir$fpl@gnat.cs.nyu.edu> 3 siblings, 1 reply; 37+ messages in thread From: Keith Thompson @ 1995-01-14 10:37 UTC (permalink / raw) In <3f4mbe$rud@cronkite.seas.gwu.edu> dobrien@seas.gwu.edu (David O'Brien) writes: > I have to wonder. What if C defined the logical equals operator to be > "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal, > Modula-x, etc? Would this error still exist??? > > Quickly thinking about it, I feel that I write a lot more assignment > statements than local statements, couldn't I be in the habit of typing > ":=" and thus accidently type that when I meant logical comparison? > Since that would still be a perfectly valid, conforming C program, > the compiler is not required to give any warnings (just like current > practice). Thus, I would still have the same logic error in my program. > Chances of happening??? Any bodies guess. So is the problem really > one of symbol choice, or program semantics? I suspect this error would be rarer if C used ":=" for assignment. The symbol "=" is used for equality in some languages (Pascal, standard mathethematical notation, etc.) and assignment in others (Fortran, C, etc.). The symbol ":=" is used only for assignment. I don't think I've ever accidentally typed ":=" for a comparison in Ada. Digression: I once heard about a relatively obscure language that used ":" as a catenation operator. It also had C-style assignment operators. So, naturally, the statement "x := y;" assigned to x the result of catenating x and y. end Digression; Of course, if C used ":=" for assignment and "=" for comparison, the opposite error would be likely to occur; people would commonly type x = y; which, instead of assigning the value of y to x, would compare them and discard the result. This could be caught by a compiler warning; an assignment in an expression context sometimes makes sense, but a comparison in a statement context never does. It could even be forbidden, but I suppose that would violate the spirit of C. Hmm. How about ":=" and ".EQ."? 8-)} Please note that this article is not an anti-C flame; it's a theoretical discussion about programming language syntax design. Yeah, there's the ticket. -- Keith Thompson (The_Other_Keith) kst@thomsoft.com (kst@alsys.com still works) TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 When you're a nail, every problem looks like a hammer. ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <3fcjgt$b0v@cronkite.seas.gwu.edu>]
* Re: "Subtract C, add Ada" [not found] ` <3fcjgt$b0v@cronkite.seas.gwu.edu> @ 1995-01-16 18:47 ` Robert Dewar 0 siblings, 0 replies; 37+ messages in thread From: Robert Dewar @ 1995-01-16 18:47 UTC (permalink / raw) "Dennis Ritchie once said in an interview that there is *nothing* in the C language that keeps compiler writers from issuing stringent warnings about stuff that most Ada people take for granted." Dennis may have said this, but it is misleading. Yes, there is stuff that Ada people take for granted that C compilers could (and in some compilers *do*) check for. But there are lots of things that Ada people take for granted that cannot be checked in C, there just isn't enough information. C has no separation of scalar types, no ranges on scalar types, and the ubquitous use of pointers, and their similarity to arrays means that sophisticated aliasing analysis is required to even approximate the type checking that occurs in the context of access types in Ada. There are many other examples. ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <D2It0r.4rp@inmet.camb.inmet.com>]
* Re: "Subtract C, add Ada" [not found] ` <D2It0r.4rp@inmet.camb.inmet.com> @ 1995-01-17 14:11 ` Norman H. Cohen 0 siblings, 0 replies; 37+ messages in thread From: Norman H. Cohen @ 1995-01-17 14:11 UTC (permalink / raw) Just yesterday I made a one-character typo in a C program (don't ask; it puts food on the table) that preserved the legality of the program but rather radically altered its behavior. I meant to type for (i=0; i<10; i++) but my finger slipped off the shift key when I was typing "<", so it came out for (i=0; i,10; i++) which tests for loop termination by evaluating i, discarding that value, evaluating 10, and leaving the loop when 10 equals zero (i.e., never). What a language! -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <3g9nir$fpl@gnat.cs.nyu.edu>]
* Increment operator (+=) [not found] ` <3g9nir$fpl@gnat.cs.nyu.edu> @ 1995-01-28 20:23 ` Jacob Sparre Andersen [not found] ` <3gc5be$frj@Starbase.NeoSoft.COM> 1 sibling, 0 replies; 37+ messages in thread From: Jacob Sparre Andersen @ 1995-01-28 20:23 UTC (permalink / raw) Robert Dewar (dewar@cs.nyu.edu) wrote the most recent article I have read in the thread about the operator "+=" in C. In two still not mentioned languages (dialects) there are these solutions to the 'problem': In COMAL (BASIC like) there are ":+" and ":-" incrementing and decrementing 'assignments'. antal_sider:+1 rest:-1 In Borland's Pascal dialect the system library contains these procedures: Inc(var SomeInteger : <integer type> ; Step : <integer type>) ; Dec(var SomeInteger : <integer type> ; Step : <integer type>) ; I think the last solution is the right way to do it in Ada. But it's only really usefull, if any type with "+" and "-" operators can 'inherit' the procedures (I don't think that's how Ada 95 works). The Borland way (tm :-) is just how we should code. No Ada 96 :-) -- I like the idea about using local renames. -- "add 1 to long-complex-name" - What a nice readable piece of code. What's wrong with this language? :-) Regards, Jacob Sparre Andersen -- A good movie? - What about three? - Kieslowskis 'White', 'Blue' and 'Red'! -- URL's: "mailto:sparre@nbi.dk", "http://meyer.fys.ku.dk/~sparre", "mailto:sparre+@pitt.edu" & "http://www.pitt.edu/~sparre". -- "We need a plan to diverge from", Fesser ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <3gc5be$frj@Starbase.NeoSoft.COM>]
* Re: Adding in COBOL... [not found] ` <3gc5be$frj@Starbase.NeoSoft.COM> @ 1995-01-29 12:51 ` Robert Dewar 0 siblings, 0 replies; 37+ messages in thread From: Robert Dewar @ 1995-01-29 12:51 UTC (permalink / raw) David Weller says: Easy, Robert: add (1, to=> long_complex_name); Gee, I thought I'd never see the day I could teach Robert something Umm? I think you forgot something David, what is the type of the add procedure. I guess it is a generic, so don't forget to instantiate it, and oh yes, remember to pass the "+" operator to the generic while you are at it (wouldn't want the dread reemergence doing us in), and also remember to inline it (and hope that inlining generic instances works fine and .... ^ permalink raw reply [flat|nested] 37+ messages in thread
* Ada vs. C @ 1996-08-07 0:00 The Quelisher 1996-08-09 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 37+ messages in thread From: The Quelisher @ 1996-08-07 0:00 UTC (permalink / raw) I have found one thing that C has an advantage over Ada : executable file sizes. Everything I have programmed in Ada is HUGE compared to a program thta does the same thing but written in C. Just my $.02 -- *.........................................* . |/ . . |\ENDAL . . WWW => http://www.cs.fsu.edu/~vandyke . . EMail => kendal@freenet.scri.fsu.edu . . Pager => (904) 297-6658 . . . *.........................................* ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-07 0:00 Ada vs. C The Quelisher @ 1996-08-09 0:00 ` Robert Dewar 1996-08-09 0:00 ` The Quelisher 1996-08-12 0:00 ` Vladimir Vukicevic 1996-08-09 0:00 ` Jack W Scheible 1996-08-09 0:00 ` Daniel P Hudson 2 siblings, 2 replies; 37+ messages in thread From: Robert Dewar @ 1996-08-09 0:00 UTC (permalink / raw) The Quelisher says "I have found one thing that C has an advantage over Ada : executable file sizes. Everything I have programmed in Ada is HUGE compared to a program thta does the same thing but written in C." That's bogus, comparable programs in Ada and C will generate executables of the same size, at least using a technology like GNAT. You have however to be careful about that "comparable". Note for example that in GNAT, by default the executable files contain debugging information which is typically much more voluminous than the code itself -- so make sure you are comparing stripped file sizes. Second, in some version of GNAT, the default is to link statically, and in others to link dynamically. Be careful you are not comparing a statically linked Ada program to a dynamically linked C program. It's true that in the default configuration on some ports of GNAT, the exe files will be bigger, due in particular to the inclusion by default of debugging information. This choice of defaults is deliberate and reflects the fact that disk prices have dropped dramatically, so the gain from having the debugging information around seems worth the space (after all a 300K file these days is occupying 5 cents worth of disk space). Note also that it is ONLY a space issue, the debugging information is not loaded if you are not debugging. But anyway, if you don't want the debugging information, just make sure it is stripped. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-09 0:00 ` Robert Dewar @ 1996-08-09 0:00 ` The Quelisher 1996-08-10 0:00 ` Robert Dewar ` (4 more replies) 1996-08-12 0:00 ` Vladimir Vukicevic 1 sibling, 5 replies; 37+ messages in thread From: The Quelisher @ 1996-08-09 0:00 UTC (permalink / raw) Robert Dewar wrote: > That's bogus, comparable programs in Ada and C will generate > executables of the same size, at least using a technology like GNAT. Ok, so let me explain where I am coming from then. Here is the source in both languages that does the exact same very basic thing: ----------------------------------------------------------------------- C : main() { printf("Hello world! \n"); } ----------------------------------------------------------------------- Ada : WITH Ada.Text_IO; USE Ada.Text_IO; PROCEDURE hello IS BEGIN Put_line("Hello world!"); END hello; ----------------------------------------------------------------------- When I compiled each of the above here are the file sizes that resulted: C ----> 24,576 Ada --> 253,952 I used gcc to compile the C code and gnatmake for the Ada code, both on unix machines. Now that's what I meant by the difference in file sizes. I understand though that there is a tradeoff between file size and functionability of a program, but let's take PC's for example. Who wants to run a 6 mb program written in Ada when a 2mb program written in C does the same thing? I'm not trying to knock Ada or anything, rather just making an observation. Again, just my $.02 -- *.........................................* . |/ . . |\ENDAL . . WWW => http://www.cs.fsu.edu/~vandyke . . EMail => kendal@freenet.scri.fsu.edu . . Pager => (904) 297-6658 . . . *.........................................* ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-09 0:00 ` The Quelisher @ 1996-08-10 0:00 ` Robert Dewar 1996-08-10 0:00 ` steved ` (3 subsequent siblings) 4 siblings, 0 replies; 37+ messages in thread From: Robert Dewar @ 1996-08-10 0:00 UTC (permalink / raw) The Quelisher said "When I compiled each of the above here are the file sizes that resulted: C ----> 24,576 Ada --> 253,952" So what? this does not prove, or even relate to your point, and it is certainly complete nonsense to take this observation and deduce from it that a 6 megabyte Ada program will correspond to a 2 megabyte C program. Why are the above figures not relevant. First: the size of an executable file is not related to the size of the executable program in any simple way. Two factors are of critical importance. First, are they both stripped or not, I am willing to bet that the Ada file was not stripped -- so why didn't you strip it to make the comparison. Second, I would guess the Ada program is statically linked, and the C program is dynamically linked, meaning that the space for Text_IO is included in the Ada size you see, and the space for printf is not included in the C file that you see. Finally, and most importantly, these are quite different programs, one uses the package printf, and the oher uses the package Text_IO. Yes, there is some overlap in capability, but they are definitely not the same package, and both contain functionality not in the other. If you want to persue this, first make sure you understand what stripping is about, and also what dynamic vs static linking is about, so that these factors do not make your observations meaningless, and then compare programs that are comparable! ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-09 0:00 ` The Quelisher 1996-08-10 0:00 ` Robert Dewar @ 1996-08-10 0:00 ` steved 1996-08-10 0:00 ` Robert Dewar 1996-08-10 0:00 ` Bob Kitzberger ` (2 subsequent siblings) 4 siblings, 1 reply; 37+ messages in thread From: steved @ 1996-08-10 0:00 UTC (permalink / raw) The Quelisher <kendal@freenet.scri.fsu.edu> writes: >Robert Dewar wrote: >> That's bogus, comparable programs in Ada and C will generate >> executables of the same size, at least using a technology like GNAT. > >Ok, so let me explain where I am coming from then. Here is the source in >both languages that does the exact same very basic thing: >----------------------------------------------------------------------- >C : > main() > { > printf("Hello world! \n"); > } > >----------------------------------------------------------------------- >Ada : > > WITH Ada.Text_IO; USE Ada.Text_IO; > PROCEDURE hello IS > BEGIN > Put_line("Hello world!"); > END hello; >----------------------------------------------------------------------- > >When I compiled each of the above here are the file sizes that resulted: > C ----> 24,576 > Ada --> 253,952 > I think you'll find that if you add another ten lines of code to your example, the size of the Ada executable will NOT increase proportionally. Yes, for small app's C will come out smaller. But for real reasonably sized app's I think you'll find the sizes to be comparable. My Opinion, Steve Doiel steved@pacifier.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-10 0:00 ` steved @ 1996-08-10 0:00 ` Robert Dewar 0 siblings, 0 replies; 37+ messages in thread From: Robert Dewar @ 1996-08-10 0:00 UTC (permalink / raw) Here is some realistic data on comparing C and Ada. The programs I compared are: In Ada procedure f is procedure printf (s : string); pragma Import (C, printf, "printf"); begin printf ("Hello World!"); end f; In C #include <stdio.h> main(int argc, char *argv[], char *envp[]) { printf("hello world\n"); } The stripped executables compiled by gcc are of course identical in size as one would expect, 24580 bytes in either case. I used printf in both programs so that they are exactly comparable. Now of course if you include an additional package in the Ada version, like GNAT.IO, then you will find that the Ada program gets bigger, it goes up to 32772 bytes. The additional 8200 bytes represents not some mysterious Ada inefficiency but simply the size of this package, since it is linked statically and not dynamically. If we use the more complex package Text_IO, then the size gets larger still, up to 53252 bytes. Once again, the extra 28K bytes simply represents the size of the Text_IO package. Not surprisingly it is larger than the simple GNAT.IO package since it has far more capability (it also uses some of the other Ada library facilities like finalization support). I can of course (since gcc allows mixed language programming) make a C program which uses Text_IO facilities, guess how big it is -- that's right 53252 bytes (what a surprise :-) I suppose these figures may surprise some people, but to me it would be surprising if comparable C and Ada programs were NOT the same size! ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-09 0:00 ` The Quelisher 1996-08-10 0:00 ` Robert Dewar 1996-08-10 0:00 ` steved @ 1996-08-10 0:00 ` Bob Kitzberger 1996-08-11 0:00 ` Dave Wood 1996-08-11 0:00 ` Jerry van Dijk 4 siblings, 0 replies; 37+ messages in thread From: Bob Kitzberger @ 1996-08-10 0:00 UTC (permalink / raw) The Quelisher (kendal@freenet.scri.fsu.edu) wrote: : Robert Dewar wrote: : > That's bogus, comparable programs in Ada and C will generate : > executables of the same size, at least using a technology like GNAT. [Ada vs. C hello world example] : When I compiled each of the above here are the file sizes that resulted: : C ----> 24,576 : Ada --> 253,952 But these aren't real-world programs. You'll probably discover that much of the Ada overhead is fixed -- runtime requirements for tasking (and you may be able to remove much of that if you don't use tasking). : I understand though that there is a tradeoff between file size and : functionability of a program, but let's take PC's for example. Who wants : to run a 6 mb program written in Ada when a 2mb program written in C : does the same thing? Of course no one wants to. But basing observations on "hello world" is silly. I suspect that if you use the same underlying back-end technology, the size of the Ada vs. C programs will increase at roughly the same rate, once you ignore the fixed-size runtime costs. -- Bob Kitzberger Rational Software Corporation rlk@rational.com http://www.rational.com http://www.rational.com/pst/products/testmate.html ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-09 0:00 ` The Quelisher ` (2 preceding siblings ...) 1996-08-10 0:00 ` Bob Kitzberger @ 1996-08-11 0:00 ` Dave Wood 1996-08-14 0:00 ` busigin 1996-08-11 0:00 ` Jerry van Dijk 4 siblings, 1 reply; 37+ messages in thread From: Dave Wood @ 1996-08-11 0:00 UTC (permalink / raw) The Quelisher wrote: > > Robert Dewar wrote: > > That's bogus, comparable programs in Ada and C will generate > > executables of the same size, at least using a technology like GNAT. > > Ok, so let me explain where I am coming from then. Here is the source in > both languages that does the exact same very basic thing: > ----------------------------------------------------------------------- > C : > main() > { > printf("Hello world! \n"); > } > > ----------------------------------------------------------------------- > Ada : > > WITH Ada.Text_IO; USE Ada.Text_IO; > PROCEDURE hello IS > BEGIN > Put_line("Hello world!"); > END hello; > ----------------------------------------------------------------------- > > When I compiled each of the above here are the file sizes that resulted: > C ----> 24,576 > Ada --> 253,952 > > I used gcc to compile the C code and gnatmake for the Ada code, both on > unix machines. Now that's what I meant by the difference in file sizes. > I understand though that there is a tradeoff between file size and > functionability of a program, but let's take PC's for example. Who wants > to run a 6 mb program written in Ada when a 2mb program written in C > does the same thing? I'm not trying to knock Ada or anything, rather > just making an observation. Again, just my $.02 > I get the following "hello world" figures on the PC: Visual C++ 4.2 ---------------> 76.0 KB ObjectAda for Windows v7.0 ----> 89.5 KB This compares the current VC++ release against the pre-release ObjectAda compiler, both with debug symbols turned off and no special optimizations. Not much of a difference, really, especially considering that MS has had uncounted gazillions of person-years to apply to MSVC compared to the humble Ada vendor (ahem). So, I'd have to agree with Robert: if you're comparing apples and apples, there's little fundamental reason that an Ada program must be bigger than a C program. I don't see where this is a language issue, as opposed to an implementation issue. By the way, you forgot to #include <stdio.h> in your C snippet. :) -- Dave Wood -- Product Manager, ObjectAda for Windows -- http://www.thomsoft.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-11 0:00 ` Dave Wood @ 1996-08-14 0:00 ` busigin 1996-08-16 0:00 ` Robert Dewar 0 siblings, 1 reply; 37+ messages in thread From: busigin @ 1996-08-14 0:00 UTC (permalink / raw) In <320D2677.499F@thomsoft.com>, Dave Wood <dpw@thomsoft.com> writes: >The Quelisher wrote: >> >> Robert Dewar wrote: >> > That's bogus, comparable programs in Ada and C will generate >> > executables of the same size, at least using a technology like GNAT. >> >> Ok, so let me explain where I am coming from then. Here is the source in >> both languages that does the exact same very basic thing: >> ----------------------------------------------------------------------- >> C : >> main() >> { >> printf("Hello world! \n"); >> } >> >> ----------------------------------------------------------------------- >> Ada : >> >> WITH Ada.Text_IO; USE Ada.Text_IO; >> PROCEDURE hello IS >> BEGIN >> Put_line("Hello world!"); >> END hello; >> ----------------------------------------------------------------------- >> >> When I compiled each of the above here are the file sizes that resulted: >> C ----> 24,576 >> Ada --> 253,952 >> >> I used gcc to compile the C code and gnatmake for the Ada code, both on >> unix machines. Now that's what I meant by the difference in file sizes. >> I understand though that there is a tradeoff between file size and >> functionability of a program, but let's take PC's for example. Who wants >> to run a 6 mb program written in Ada when a 2mb program written in C >> does the same thing? I'm not trying to knock Ada or anything, rather >> just making an observation. Again, just my $.02 >> > >I get the following "hello world" figures on the PC: > >Visual C++ 4.2 ---------------> 76.0 KB >ObjectAda for Windows v7.0 ----> 89.5 KB > >This compares the current VC++ release against the pre-release ObjectAda >compiler, both with debug symbols turned off and no special optimizations. > >Not much of a difference, really, especially considering that MS has >had uncounted gazillions of person-years to apply to MSVC compared to >the humble Ada vendor (ahem). > >So, I'd have to agree with Robert: if you're comparing apples and >apples, there's little fundamental reason that an Ada program must >be bigger than a C program. I don't see where this is a language >issue, as opposed to an implementation issue. > >By the way, you forgot to #include <stdio.h> in your C snippet. :) > >-- Dave Wood >-- Product Manager, ObjectAda for Windows >-- http://www.thomsoft.com Using GNAT under OS/2, the hello program compiles to a 262,958 byte executable. When I strip the debug code, the size goes down to 53,252 bytes. When I run the LxLite utility program to compress the EXE file, the size goes down to 31,364 bytes. This file size is certainly not out of line with C/C++ compilers. Anthony Busigin NITEK Corporation ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-14 0:00 ` busigin @ 1996-08-16 0:00 ` Robert Dewar 0 siblings, 0 replies; 37+ messages in thread From: Robert Dewar @ 1996-08-16 0:00 UTC (permalink / raw) Anthony said "Using GNAT under OS/2, the hello program compiles to a 262,958 byte executable. When I strip the debug code, the size goes down to 53,252 bytes. When I run the LxLite utility program to compress the EXE file, the size goes down to 31,364 bytes. This file size is certainly not out of line with C/C++ compilers. " And if you link dynamically instead of staticaly, you can of course reduce the executable size much further. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-09 0:00 ` The Quelisher ` (3 preceding siblings ...) 1996-08-11 0:00 ` Dave Wood @ 1996-08-11 0:00 ` Jerry van Dijk 4 siblings, 0 replies; 37+ messages in thread From: Jerry van Dijk @ 1996-08-11 0:00 UTC (permalink / raw) The Quelisher (kendal@freenet.scri.fsu.edu) wrote: : Robert Dewar wrote: : > That's bogus, comparable programs in Ada and C will generate : > executables of the same size, at least using a technology like GNAT. : printf("Hello world! \n"); : Put_line("Hello world!"); : When I compiled each of the above here are the file sizes that resulted: : C ----> 24,576 : Ada --> 253,952 To me this looks like comparing a C program using shared libraries to a statically linked Ada program... Besides, what do you think you are comparing here ? With only one line of executable code, the programs mainly consist of the program start-up code and runtime library. And then I would expect the GNAT executable to be somewhat larger then the C one, since the GNAT RTL contains more functionality (like tasking). If you really want to compare executable file sizes, you should use two equivalent programs, large enough to make size of the RTL insignificant compared to the code size. But, then, whats the point to it... P.S. Under DOS a GNAT hello world is about 87K, a gcc one about 57K. If I were to use a 16-bit C compiler I would expect a 6K exe size. Using an embedded systems compiler would bring that down to about 500 bytes. If that is still to big, handwritten assembler will get away with about 40 bytes. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-09 0:00 ` Robert Dewar 1996-08-09 0:00 ` The Quelisher @ 1996-08-12 0:00 ` Vladimir Vukicevic 1 sibling, 0 replies; 37+ messages in thread From: Vladimir Vukicevic @ 1996-08-12 0:00 UTC (permalink / raw) dewar@cs.nyu.edu (Robert Dewar) writes: > > Here is some realistic data on comparing C and Ada. The programs I > compared are: > > [..] > > The stripped executables compiled by gcc are of course identical in > size as one would expect, 24580 bytes in either case. > [..] > I can of course (since gcc allows mixed language programming) make a C > program which uses Text_IO facilities, guess how big it is -- that's right > 53252 bytes (what a surprise :-) > > I suppose these figures may surprise some people, but to me it would > be surprising if comparable C and Ada programs were NOT the same size! Come on, Robert, you can't really believe that C and Ada programs compile into the exact same size, no matter how identical they are. They are very close in size: (f being the ada code, and foo being the C code) -rw-rw-r-- 1 vladimir vladimir 896 Aug 12 15:37 f.o -rw-rw-r-- 1 vladimir vladimir 880 Aug 12 15:38 foo.o However, when compiled into full apps, the ada code needs to have gnatbind needs to do various initialization, and only then call procedure f(). In C, this isn't necessary; as such, the resulting executable files have the following sizes [stripped, all libraries shared]: -rwxrwxr-x 1 vladimir vladimir 6692 Aug 12 15:46 f* -rwxrwxr-x 1 vladimir vladimir 2436 Aug 12 15:47 foo* Why the large size discrepancy? Because f is being linked (albeit shared) with libgnat, libc, libpthread, and libm. foo, on the other hand, is just being linked shared with libc. f also has the overhead of b_f.c, whereas foo does not. This is all rather pointless, actually, since executable file size doesn't have anything to do with memory requirements of the program or running time or whatnot. For comparison purposes, here is an equivalent program in java: public class F { public static void main (String args[]) { System.out.println ("hello world"); } } The resulting runnable code size? -rw-rw-r-- 1 vladimir users 407 Aug 12 15:51 F.class I guess this makes java twice as good as Ada and C :-) - Vladimir -- Vladimir Vukicevic <vladimir@arp.com> [std disclaimer here] C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-07 0:00 Ada vs. C The Quelisher 1996-08-09 0:00 ` Robert Dewar @ 1996-08-09 0:00 ` Jack W Scheible 1996-08-09 0:00 ` Daniel P Hudson 2 siblings, 0 replies; 37+ messages in thread From: Jack W Scheible @ 1996-08-09 0:00 UTC (permalink / raw) In article <3208F2BA.E34@freenet.scri.fsu.edu> kendal@freenet.scri.fsu.edu writes: >I have found one thing that C has an advantage over Ada : executable >file sizes. Everything I have programmed in Ada is HUGE compared to a >program thta does the same thing but written in C. Disk space is cheap, program maintenance is not. -jack ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-07 0:00 Ada vs. C The Quelisher 1996-08-09 0:00 ` Robert Dewar 1996-08-09 0:00 ` Jack W Scheible @ 1996-08-09 0:00 ` Daniel P Hudson 1996-08-09 0:00 ` Robert Dewar 2 siblings, 1 reply; 37+ messages in thread From: Daniel P Hudson @ 1996-08-09 0:00 UTC (permalink / raw) The Quelisher <kendal@freenet.scri.fsu.edu> wrote: >I have found one thing that C has an advantage over Ada : executable >file sizes. Everything I have programmed in Ada is HUGE compared to a >program thta does the same thing but written in C. >Just my $.02 Psst, over here. That's a feature of the COMPILER, not the language. Plus, any OO language will compile larger a structured langauge because of the overhead OO requires. If you don't understand this, let me clarify. Years ago, when Microsofts Quick_C 1.0 was still a major sought after item by those trying to learn C, I was told by a close-minded friend that I was wasting my time writting my programs in Quick_Basic. Besides being the most unintelligent statement I had ever heard, after all these were my programs for MY computer and they appeared to be working just fine to me, it was a challenge which I accepted. I asked him why and he told me the code was slow and too big. My friend had never even seen a Basic compiler so this was his first shock, his second was when QuickBasic 4.5 mainly matched QC 1.0 in the final output tests. The language had nothing to do with it, the compilers were from the same general time era and the company implemented the same technology in both. The library was the only that determined which was better, and QB didn't give you the control over FP that QC did, so QC had one advantage. Now, in today, most language are equivalent in such tests because compiler technology is shared quite freely due to projects like GNU or the newsgroup comp.compilers and freely available docs on a variety of architectures. However, if you compile these two sources /* c */ #include <stdioh.> int main(void) { printf("Hello, World!\n"); return 0; } -------------------------------------------------------------------- // cpp #include <iostream.h> int main(void) { cout << "Hello, World!" << endl; return 0; } I guarentee you that the C code will always come out smaller than the C++ equivalent will, due to OO overhead. Ada uses OO, even thouhgh you can code in a proceedural fashion, the standard libs are designed to be used in OO programming and therefore carry the OO overhead. Is this a bad thing? Only if you don't feel that an OO approach is the best solution to your current task, but it does seem that the CIS community is moving toward OOP. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Ada vs. C 1996-08-09 0:00 ` Daniel P Hudson @ 1996-08-09 0:00 ` Robert Dewar 0 siblings, 0 replies; 37+ messages in thread From: Robert Dewar @ 1996-08-09 0:00 UTC (permalink / raw) Daniel said " I guarentee you that the C code will always come out smaller than the C++ equivalent will, due to OO overhead. Ada uses OO, even thouhgh you can code in a proceedural fashion, the standard libs are designed to be used in OO programming and therefore carry the OO overhead. Is this a bad thing? Only if you don't feel that an OO approach is the best solution to your current task, but it does seem that the CIS community is moving toward OOP." I have no idea what this means. The standard libraries consist, at least in GNAT, of hundreds of separate units, some of which use some features of OO (not many), most of which do not. There is no inherent OO overhead. Your guarantee with respect to C and C++ is also completely odd. Indeed since C++ is largely a subset of C, the typical C++ code that corresponds to the C code is identical to the C code, and in any reasonable compilation environment generates exactly the same bits as the C code. ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~1996-08-16 0:00 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3etund$hnr@miranda.gmrc.gecm.com> 1995-01-12 9:56 ` "Subtract C, add Ada" Erik Svensson [not found] ` <3f0n6b$qnp@theopolis.orl.mmc.com> [not found] ` <3f3cq3$4tu@gnat.cs.nyu.edu> 1995-01-12 14:25 ` uninitialzed variables Richard Kenner 1995-01-12 14:44 ` "Subtract C, add Ada" Norman H. Cohen 1995-01-13 1:51 ` David O'Brien 1995-01-13 12:38 ` Laurent Gasser 1995-01-13 20:53 ` John DiCamillo [not found] ` <3f8fnf$c8p@gamma.ois.com> 1995-01-16 11:02 ` Matt Kennel [not found] ` <milodD2IFpG.329@netcom.com> 1995-01-17 21:39 ` R. William Beckwith [not found] ` <3fa11q$sdh@gnat.cs.nyu.edu> 1995-01-16 20:20 ` David Moore 1995-01-14 0:24 ` David O'Brien 1995-01-20 4:43 ` Samuel Mize 1995-01-21 20:28 ` David O'Brien 1995-01-22 21:12 ` Robert Dewar 1995-01-23 18:35 ` Norman H. Cohen 1995-01-23 19:18 ` John Cosby - The Coz 1995-01-24 14:11 ` Samuel Mize [not found] ` <3g655n$q5k@theopolis.orl.mmc.com> 1995-01-30 15:33 ` Ada vs. C Martijn Bak 1995-01-14 10:37 ` "Subtract C, add Ada" Keith Thompson [not found] ` <3fcjgt$b0v@cronkite.seas.gwu.edu> 1995-01-16 18:47 ` Robert Dewar [not found] ` <D2It0r.4rp@inmet.camb.inmet.com> 1995-01-17 14:11 ` Norman H. Cohen [not found] ` <3g9nir$fpl@gnat.cs.nyu.edu> 1995-01-28 20:23 ` Increment operator (+=) Jacob Sparre Andersen [not found] ` <3gc5be$frj@Starbase.NeoSoft.COM> 1995-01-29 12:51 ` Adding in COBOL Robert Dewar 1996-08-07 0:00 Ada vs. C The Quelisher 1996-08-09 0:00 ` Robert Dewar 1996-08-09 0:00 ` The Quelisher 1996-08-10 0:00 ` Robert Dewar 1996-08-10 0:00 ` steved 1996-08-10 0:00 ` Robert Dewar 1996-08-10 0:00 ` Bob Kitzberger 1996-08-11 0:00 ` Dave Wood 1996-08-14 0:00 ` busigin 1996-08-16 0:00 ` Robert Dewar 1996-08-11 0:00 ` Jerry van Dijk 1996-08-12 0:00 ` Vladimir Vukicevic 1996-08-09 0:00 ` Jack W Scheible 1996-08-09 0:00 ` Daniel P Hudson 1996-08-09 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox