* 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ messages in thread
end of thread, other threads:[~1995-01-30 15:33 UTC | newest] Thread overview: 22+ 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox