* Easily-Read C++? @ 1994-10-05 3:00 Ken Garlington 1994-10-05 9:42 ` Pierre Castori ` (5 more replies) 0 siblings, 6 replies; 43+ messages in thread From: Ken Garlington @ 1994-10-05 3:00 UTC (permalink / raw) Robin Rowe <cpp@NETCOM.COM> writes: << Here's how I read a piece of C++ code: if(!object) // "If not object [then]" { cerr<<object.ErrorMsg(); // "output object's error } // message," else // "else" { object++; // "increment object." } So what's unnatural about this? Sounds like English to me. >> Not that I'm a C++ expert, but I have noticed that a lot of C/C++ code looks like Greek to me. Certainly, that stuff on the right reads like English to me (is this normal C style to comment every line?) but the stuff on the left I have to think about a little. On the other hand: If Not(object) then Text_IO.Put_Line (Error_Message (corresponding_to => object)); else object := object + 1; end if; is easily read by _any_ engineer (never mind software engineer) on my project. (Of course, I would have to explain what the "not" of a numeric value is, maybe, but a more meaningful function name is probably a good idea in this case.) In fact, it looks suspiciously like the English explanation of the C code. Note that some of these engineers didn't take the math class where "++" means "add one to the thing before the ++." However, "X = X + 1" is something they got pretty early on. That colon hanging off the equal sign doesn't seem to bother them much. Has anyone tried a study like the following? Take some C++ code from Software Development, or Embedded Systems Programming, or whatever. Write the Ada 9X equivalent. Show the 9X code to C++ programmers who have never seen Ada, and the C++ code to Ada programmers who haven't worked with C recently. Which set of code would be understood more often? ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-05 3:00 Easily-Read C++? Ken Garlington @ 1994-10-05 9:42 ` Pierre Castori 1994-10-05 13:28 ` Robert Dewar 1994-10-05 14:26 ` Easily-Read C++? Eric S. Sessoms ` (4 subsequent siblings) 5 siblings, 1 reply; 43+ messages in thread From: Pierre Castori @ 1994-10-05 9:42 UTC (permalink / raw) In article <941005030023_73672.2025_DHR103-1@CompuServe.COM>, Ken Garlington <73672.2025@COMPUSERVE.COM> writes: |> |> Robin Rowe <cpp@NETCOM.COM> writes: |> |> |> |> Before I begin, I want to make two things clear. One, that I intend |> |> no disrespect to the author of the original paper, and two, that I |> |> am an expert in C++ but not in Ada. |> |> |> |> [lots of stuff deleted] |> |> |> |> << Here's how I read a piece of C++ code: |> |> |> |> if(!object) // "If not object [then]" |> |> { cerr<<object.ErrorMsg(); // "output object's error |> |> } // message," |> |> else // "else" |> |> { object++; // "increment object." |> |> } |> |> |> |> So what's unnatural about this? Sounds like English to me. >> |> |> Of course! Didn't you say you were a C++ expert? Would look weird if you couldn't understand this easily don't you think so? By the way, what about the same code without the comments? ... |> Not that I'm a C++ expert, but I have noticed that a lot of C/C++ code looks |> like Greek to me. Certainly, that stuff on the right reads like English to me |> (is this normal C style to comment every line?) but the stuff on the left I |> have to think about a little. On the other hand: |> |> If Not(object) then |> Text_IO.Put_Line (Error_Message (corresponding_to => object)); |> else |> object := object + 1; |> end if; |> |> is easily read by _any_ engineer (never mind software engineer) on my project. |> (Of course, I would have to explain what the "not" of a numeric value is, |> maybe, but a more meaningful function name is probably a good idea in this |> case.) In fact, it looks suspiciously like the English explanation of the C |> code. Note that some of these engineers didn't take the math class where "++" |> means "add one to the thing before the ++." However, "X = X + 1" is something |> they got pretty early on. That colon hanging off the equal sign doesn't seem to |> bother them much. |> Totally agreed. I can't understand how people can honestly claim C or C++ are as readable as Ada. More generally did you realize how often C/C++ programmers use abbreviations? They seem to implicitly admit that what they are writing will be understood. And this seems to be automatic in the C community. This probably comes from the times when people were taught C. You learn to use good old int (integer), rd (read) and fd (file descriptor). Then it is natural to continue using such abbreviations. What is the big deal in writing file_descriptor? Laziness? Why cerr and Msg in the example above? Agreed that ErrorMsg is understandable. But again what is the problem in writing Error_Message? Especially with nowadays editors that have so many features to help you complete words, indent automatically, etc. Comparatively, Ada programmers seldom abbreviate. I am not saying they never do it. I am saying the tendency in the Ada community is naturally not to use abbreviations (ease of reading). While the tendency in the C community is naturally to use abbreviations (ease of writing). The C/C++ languages themself are designed with some sort of a compact-statements-do-a-lot principle. Abbreviations make programs much more difficult to read and understand. In writing programs, I think many programmers forget the well-known principle: a program is written once, read many. And "many" means many other people than the author! |> Has anyone tried a study like the following? Take some C++ code from Software |> Development, or Embedded Systems Programming, or whatever. Write the Ada 9X |> equivalent. Show the 9X code to C++ programmers who have never seen Ada, and |> the C++ code to Ada programmers who haven't worked with C recently. Which set |> of code would be understood more often? Guess ... ;-) In computer science papers that present some algorithms, it is seldom the case that these algorithms are described in a C-like fashion. Most often, a Pascal-like solution is used even when the algorithm is really implemented in C/C++. Howcome? I thought C was THE widely accepted language. For me, this says it all. //Pierre. ============================================================================ | Pierre Castori | Tel : +41 21 693 2054 | | Dept. of Computer Science | Fax : +41 21 693 4701 | | Swiss Federal Institute of Technology |-------------------------------| | EPFL - IN ECUBLENS ______| Email: castori@litsun.epfl.ch | | 1015 Lausanne (SWITZERLAND) | http://litwww.epfl.ch/~castori/.html | ============================================================================ ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-05 9:42 ` Pierre Castori @ 1994-10-05 13:28 ` Robert Dewar 1994-10-06 2:20 ` Benjamin Ketcham [not found] ` <CxDL8H.KGE@csn.org> 0 siblings, 2 replies; 43+ messages in thread From: Robert Dewar @ 1994-10-05 13:28 UTC (permalink / raw) The point that C and C++ programmers tend to use abreviations and in general short identifiers, where as Ada programmers tend to use long fully spelled out names is a pretty important one. Because, good choice of names is often critical to readability of code (more critical than the basic syntactic structure of the language -- Basic with good names can be much more readable than Ada with junk short names). So, it isn't a language issue at all? right? you can perfectly well use nice names in C++ (or for that matter Basic) if you want to. Well, I am not so sure that this is not a language issue. THe trouble with C, inherited by C++, is that it has a lot of very neat notations that somehow are much nicer and neater with short names (much the same could be said of many traditional mathematical notations, mathematicians tend to call a function f, rather than Second_Order_Bessel_Function, but then their "programs" are usually short). i++ that's a nice neat notation, especially when composed in a complex expression, but Average_Daily_Rate_Of_Pay++ makes people laugh (I tell that as a joke, and C programmers as well as Ada programmers laugh). somehow, the ++ just ain't so neat in the context of long names. How important is this effect? I don't know! To what extent does it explain the empirical observation of difference in style between C++ programmers and Ada programmers? I don't know! I hasten to add that the universal quantifiers here are of course bogus, not ALL C++ programmers choose junk names, and not all Ada programmers choose good names (the most noticable counter examples I have seen in both cases come from recently translplanted programmers, C++ programmers trying to write Ada, or vice versa). I would also add to this thread that the mere fact that there exists a person who can easily read X does not mean that X is readable. I once had a student who gaily wrote thousands of lines of uncommented assembly language, and could read it just fine :-) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-05 13:28 ` Robert Dewar @ 1994-10-06 2:20 ` Benjamin Ketcham [not found] ` <CxDL8H.KGE@csn.org> 1 sibling, 0 replies; 43+ messages in thread From: Benjamin Ketcham @ 1994-10-06 2:20 UTC (permalink / raw) In article <36ui0u$4dg@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Maybe the C line should be > > p(j,b,t) > >since it seems out of style to use those long names :-) Robert: You'd be a lot easier to take seriously (and since you are obviously very knowledgeable I believe that taking you seriously is generally a good idea) if you could resist the temptation to jump on every opportunity to make gratuitous and unwarranted jabs at C/C++. Not everyone who reads this newsgroup is a completely dedicated and rabid Ada zealot who sees no utility whatever in any other language, so be careful about assuming you are preaching to the converted. (I could make a jab of my own about Ada right here, but I won't.) The irony is, if I'm not highly mistaken, I think I've heard you yourself complain from time to time about the poor signal/noise ratio in this very newsgroup due to "language-bashing". I guess you haven't looked at much X11 code if you think C programmers like to use short names! Personally, I almost wonder whether problems might arise occasionally due to names that do not differ within the guaranteed minimum-significant number of characters (32, is it?).... Sure, *some* C programmers use illegibly-short names, just as probably *some* Ada programmers don't do enough thinking about program design and robustness because they assume the compiler will protect them. If the former are the rule, rather than the exception, in your universe, then perhaps we just live in different universes. --ben PS: I don't have a problem with ++really_long_and_descriptive_variable_name; It certainly looks better to me than really_long_and_descriptive_variable_name := really_long_and_descriptive_variable_name + 1; (Geez, had to use the editor to facilitate writing that last bit, and if you really believe that it's more readable than the first one, particularly if it were in a "real-world" context where there might be dozens of variables beginning with, e.g., "really_long_and_", then I'll just have to respectfully decline to agree.) ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <CxDL8H.KGE@csn.org>]
[parent not found: <milodCxH2E4.7F4@netcom.com>]
[parent not found: <CxHJv0.Kw0@csn.org>]
* Re: Easily-Read C++? [not found] ` <CxHJv0.Kw0@csn.org> @ 1994-10-12 17:03 ` John DiCamillo [not found] ` <DAG.94Oct11080229@bellman.control.lth.se> 1 sibling, 0 replies; 43+ messages in thread From: John DiCamillo @ 1994-10-12 17:03 UTC (permalink / raw) perez@oldcolo.com (Carlos Perez) writes: >John DiCamillo (milod@netcom.com) wrote: >: perez@oldcolo.com (Carlos Perez) writes: >: >i use 2 pgm n ada bt i chngd to oth pgm lang cuz ada usd 2 mny ltrs & >: >evry1 thnx c s btr; i ms ada bt i cn wrt kwik now; >: You forgot to mention how much easier >: it is for you to read vanity license >: plates since you started using C. >: All that practice with cryptically >: abreviated variable names, you know. >: Great post! >In retrospect, I think I was a bit too cynical. I apologize to the many >competent and knowledgable C and C++ programers who do write readable >code. Apology accepted! ;-) But this whole variable name length argument is really beside the point. (Reason: neither language enforces or even encourages short variable or type names. People use certain naming conventions because that's the way they were taught, or because a standard is enforced for a project.) But there are many other aspects of program readability. Other people have jumped on C++'s cryptic pure virtual notation (a wart or at least a very bad pun) and its mostly hideous declaration style (inherited from C). Another place where readability suffers is inside class templates (generics). This problem is partly due to templates being hurried into the language without adequate testing. But even given all that, I still like C++ syntax because it is concise. This allows me to read unfamiliar code more quickly, and to establish a mental schema for the abstrac- tions more quickly. Eiffel provides this through 'short-flat' and Ada through package specifications, but I think that C++ is more effectively concise than those languages. I'll readily admit it's not much of an argument, but at least it's better than yammering away about "mine's longer than yours". -- c'iao, milo ================================================================ John DiCamillo Pinin' for the fjords? milod@netcom.com What kind of talk is that? ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <DAG.94Oct11080229@bellman.control.lth.se>]
[parent not found: <37du0k$ir2@gnat.cs.nyu.edu>]
* Re: Attractive comments better? [not found] ` <37du0k$ir2@gnat.cs.nyu.edu> @ 1994-10-12 3:19 ` R_Tim_Coslet 1994-10-13 1:35 ` Michael Feldman 1 sibling, 0 replies; 43+ messages in thread From: R_Tim_Coslet @ 1994-10-12 3:19 UTC (permalink / raw) >One important key to writing readable C and C++ programs is to treat headers >as the full equivalent of Ada specs, and comment them appropriately. >Historically, many C programmers treat headers as a kind of annoyance >required by the silly compiler which can't figure it out for itself, >and write the absolute minimum of text in headers with minimal comments. Or worse yet, I've seen a few C programmers actually putting CODE (not just declarations but actual CODE) in some header files! This results in programs that mysteriously grow RAPIDLY in size of executable :-( I couldn't believe it the first time I encountered it, at least Ada simply will NOT let you even attempt this! R. Tim Coslet Usenet: R_Tim_Coslet@cup.portal.com technology, n. domesticated natural phenomena ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Attractive comments better? [not found] ` <37du0k$ir2@gnat.cs.nyu.edu> 1994-10-12 3:19 ` Attractive comments better? R_Tim_Coslet @ 1994-10-13 1:35 ` Michael Feldman 1 sibling, 0 replies; 43+ messages in thread From: Michael Feldman @ 1994-10-13 1:35 UTC (permalink / raw) In article <37du0k$ir2@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Note that I am perfectly aware that some C/C++ programmers fully understand >the structural importance of headers, but a distressing amount of code, even >on large systems, is written without this awareness, and the headers are >an uncommented mess. And an amazing number of C books do not even take cognizance of the notion that a header file can be used for this purpose (equivalent to an Ada spec). I went shopping for intro C books recently, to find one I could use in my file structures course, in which I'm easing the students from Ada to "C with an Ada accent". I had 4 main criteria for a book, which narrowed the search from _hundreds_ (in the Computer Literacy Bookshop) to just a very few: 1. diskette of programs, and (better) a compiler shrink-wrapped; 2. suitable for self-teaching (I'm not going to teach C ab initio, because the students have had 2.5 semesters of Ada and some assembler already; 3. did justice to files, especially binary ones; 4. used headers adequately It was _very_ tough to find one. In the end, 3 and 4 got lower priority than 1 and 2. But looking at all the junk books on the market, one can easily see where all the junk code comes from. >Now of course people could write similar useless messy Ada specs, but both >the language and the culture emphasize the importance of specs so >energetically that this is relatively unusual in the Ada world. > And the C culture, in general, emphasizes it very little. Mike Feldman ------------------------------------------------------------------------ Michael B. Feldman - chair, SIGAda Education Working Group Professor, Dept. of Electrical Engineering and Computer Science The George Washington University - Washington, DC 20052 USA 202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet) "Non illegitimi carborundum." (Don't let the bastards grind you down.) ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-05 3:00 Easily-Read C++? Ken Garlington 1994-10-05 9:42 ` Pierre Castori @ 1994-10-05 14:26 ` Eric S. Sessoms 1994-10-05 17:47 ` Kevin Cline ` (3 subsequent siblings) 5 siblings, 0 replies; 43+ messages in thread From: Eric S. Sessoms @ 1994-10-05 14:26 UTC (permalink / raw) On Tue, 4 Oct 1994, Ken Garlington wrote: > Robin Rowe <cpp@NETCOM.COM> writes: > > << Here's how I read a piece of C++ code: > > if(!object) // "If not object [then]" > { cerr<<object.ErrorMsg(); // "output object's error > } // message," > else // "else" > { object++; // "increment object." > } > > So what's unnatural about this? Sounds like English to me. >> I've been giving a lot of thought to this readability issue, since as a native C/C++ speaker, I find the readability of Ada to be one of its strong points. BUT, the factors I find contribute most to the readability of Ada do not include its "englishness". Rather, some of the language features such as subrange types, arbitrarily bounded arrays, and arrays over enumerated or character types seem (to me) to make the greatest contribution. (And nested procedure declarations, can't forget that!) Now, as Robin Rowe pointed out, these are not foreign concepts in C++. In fact, they are all rather trivial given the wonderful C++ template mechanism, but that's where they fall. *The necessary templates are not standard.* By taking these low level concepts as part of the language, Ada has standardized a much larger part of what (some) programmers (like me) do. The net effect is that in moving from one person's code to another (or one shop's code to another, if they impose shop standards) there is a slight decrease in reading effort from not having to re-learn how Coder X has chosen to implement a few necessary low-level concepts. just to throw in some pseudo-code: enum days_of_week { sunday, monday, tuesday, wednesday, ..., saturday }; typedef Bounded<days_of_week, monday, friday> week_days; Array<week_days, int> beers_drank; beers_drank[wednesday] = 0; Having only one integer type is also nice. Why, nearly as nice as "class Integer {...};"! Do you see my point? I really doubt there is much in Ada that you can't have in C++, but in Ada it is (1) easier and (2) standardized -- so convince me that standardization gives you something more than a larger language standard. IMHO, it helps _a_lot_. IMHO, it will all be moot once standardized C++ class libraries become commonly available. Responses? Ideas? Criticisms? I'm very tired of "'begin end' is better than '{ }'" arguments, and the "Ada programmers use longer names" arguments, but I would be very interested in any further discussion of what language elements contribute either to the readability of Ada or of C++. Please post follow-ups here and direct all flames to: eric sessoms (sesse@ruby.ils.unc.edu) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-05 3:00 Easily-Read C++? Ken Garlington 1994-10-05 9:42 ` Pierre Castori 1994-10-05 14:26 ` Easily-Read C++? Eric S. Sessoms @ 1994-10-05 17:47 ` Kevin Cline 1994-10-05 22:02 ` Robert Dewar 1994-10-05 18:24 ` Magnus Kempe ` (2 subsequent siblings) 5 siblings, 1 reply; 43+ messages in thread From: Kevin Cline @ 1994-10-05 17:47 UTC (permalink / raw) It doesn't matter how readable a programming language is to inexperienced users of that language. Most people required to read code in C or Ada end up reading a lot of it. It takes me longer to read Ada, even after 3 years experience, because there are more characters to look at. Every field of human endeavor has created special words & symbols to save time both in writing and reading. Ada's attempt to make code read more like natural language opposes a trend that began with the invention of writing. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-05 17:47 ` Kevin Cline @ 1994-10-05 22:02 ` Robert Dewar 1994-10-05 22:23 ` Richard Kenner 0 siblings, 1 reply; 43+ messages in thread From: Robert Dewar @ 1994-10-05 22:02 UTC (permalink / raw) Right, and comments also slow down you reading because they add unnecessary characters .. I certainly know far too many programmers who think that way ... ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-05 22:02 ` Robert Dewar @ 1994-10-05 22:23 ` Richard Kenner [not found] ` <124377@cup.portal.com> 0 siblings, 1 reply; 43+ messages in thread From: Richard Kenner @ 1994-10-05 22:23 UTC (permalink / raw) In article <36v7p4$amf@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes: >Right, and comments also slow down you reading because they add unnecessary >characters .. I certainly know far too many programmers who think that >way ... There are actually times when it can! Consider the following fragment of an assembler language program for the PDP-11 written by someone who was told to write a comment on every line: ADD #1,R0 ;Add one to R0. That actually *does* slow down reading! One company, either DEC (I think) or CDC (less likely) actively discouraged this sort of thing in their coding standard. ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <124377@cup.portal.com>]
* Re: Easily-Read C++? [not found] ` <124377@cup.portal.com> @ 1994-10-11 18:11 ` David Weller 1994-10-11 18:43 ` Robert Dewar 1994-10-13 0:51 ` Keith Thompson @pulsar 2 siblings, 0 replies; 43+ messages in thread From: David Weller @ 1994-10-11 18:11 UTC (permalink / raw) In article <124377@cup.portal.com>, <R_Tim_Coslet@cup.portal.com> wrote: >In article: 36v90m$9r4@cmcl2.NYU.EDU> > kenner@lab.ultra.nyu.edu (Richard Kenner) wrote: >>There are actually times when it can! Consider the following fragment >>of an assembler language program for the PDP-11 written by someone who >>was told to write a comment on every line: >> >> ADD #1,R0 ;Add one to R0. >> >>That actually *does* slow down reading! >> >Useless comments like that should be BANNED. > >If a comment can't say anything that the code doesn't already say, >either the comment shouldn't be there or maybe the comment needs >complete rethinking to ADD something that the code DOESN'T say (e.g. >what is in R0? "Add one to counter" or "Increment flight level" would >be MUCH more informative than simply repeating the code). Ben Brosgol wrote an article many years ago on correct commenting. He pointed out that the only thing worse than commenting the above code as "Increment R0 by 1" was to say "Decrement R0 by 1" :-) -- Proud (and vocal) member of Team Ada! (and Team OS/2) ||This is not your Ada -- Very Cool. Doesn't Suck. || father's Ada For all sorts of interesting Ada tidbits, run the command: ||________________ "finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.) ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? [not found] ` <124377@cup.portal.com> 1994-10-11 18:11 ` David Weller @ 1994-10-11 18:43 ` Robert Dewar 1994-10-12 13:15 ` Norman H. Cohen 1994-10-13 0:51 ` Keith Thompson @pulsar 2 siblings, 1 reply; 43+ messages in thread From: Robert Dewar @ 1994-10-11 18:43 UTC (permalink / raw) There are to my mind three justifications for comments: Saying WHY you are doing something, and WHY you did it that way Saying WHY you did NOT do something, and WHY you did NOT Describing WHAT the code does, but at a higher level of abstraction than the code itself. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-11 18:43 ` Robert Dewar @ 1994-10-12 13:15 ` Norman H. Cohen 1994-10-12 14:10 ` Robert Firth 1994-10-13 19:33 ` John D. Reading 0 siblings, 2 replies; 43+ messages in thread From: Norman H. Cohen @ 1994-10-12 13:15 UTC (permalink / raw) In article <37emcj$sk5@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) writes: |> There are to my mind three justifications for comments: |> |> Saying WHY you are doing something, and WHY you did it that way |> |> Saying WHY you did NOT do something, and WHY you did NOT |> |> Describing WHAT the code does, but at a higher level of abstraction |> than the code itself. Another purpose is to leave advice to future maintainers about how to add enhancements that you have anticipated: -- Additional devices can be accommodated by deriving new -- types from Driver_Type. -- To add a reserved word, simply add it to the aggregate used to -- initialize Vocabulary. Add the new word in alphabetical -- order so that the binary search in Lookup will continue to work. In modifying other peoples' code, I've sometimes found comments performing another useful function as well: Utterly incoherent comments warn the reader that the original programmer had no idea what the *(^%(*$)%!! he was doing, so that the reader knows to regard the code with suspicion. My favorite comment (for honesty, if nothing else) comes from a ksh profile: #the next two lines are copied from the korn shell paper #i don't know why it works, but it seems to The runner up comes from an assembly-language program: xor R3,R4,R3 THIS IS TRICKY. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-12 13:15 ` Norman H. Cohen @ 1994-10-12 14:10 ` Robert Firth 1994-10-13 19:33 ` John D. Reading 1 sibling, 0 replies; 43+ messages in thread From: Robert Firth @ 1994-10-12 14:10 UTC (permalink / raw) In article <37gnho$nbt@watnews1.watson.ibm.com> ncohen@watson.ibm.com writes: >The runner up comes from an assembly-language program: > > xor R3,R4,R3 THIS IS TRICKY. I forget the code, but the comment that I'll never forget is ; DO A GOOD JOB ON THE SIGN BIT However, my prize for all-time ingenuity in coding goes to the programmer who was a great fan of Joni Mitchell. The labels in his program were the titles of her songs, broken up into six-character chunks. Ah, the joy of participating in a code walkthrough, and coming out of it knowing only that Joni Mitchell wrote "Song to a Seagull" - or, should I say, SONGTO ASEAGU LL... In a similar spirit, I inserted into the proof copy of the Ada Reference Manual the sentence The private type CHIPMUNK is predefined. Alas, Jean noticed (he noticed everything). ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-12 13:15 ` Norman H. Cohen 1994-10-12 14:10 ` Robert Firth @ 1994-10-13 19:33 ` John D. Reading 1 sibling, 0 replies; 43+ messages in thread From: John D. Reading @ 1994-10-13 19:33 UTC (permalink / raw) In article <37gnho$nbt@watnews1.watson.ibm.com> ncohen@watson.ibm.com writes: >My favorite comment (for honesty, if nothing else) comes from a ksh >profile: > > #the next two lines are copied from the korn shell paper > #i don't know why it works, but it seems to > >The runner up comes from an assembly-language program: > > xor R3,R4,R3 THIS IS TRICKY. > >-- >Norman H. Cohen ncohen@watson.ibm.com I am certainly liable to be flamed for wasting bandwidth, but one of my favorite comments was one I penned myself. After spending some unreasonable amount of time to get a very convoluted line of LISP code working I added the comment: ;; That's what I like about LISP - it's self documenting Those were my innocent pre-Net days; I didn't know about smileys. But to bring this back to the topic under discussion, in my experience (which includes a lot of LISP, FORTRAN, and C, and a little Ada), there are no "easily read" languages. There is no substitute for learning the language. Comments, however, are always useful for giving a more global view of *why* something was done the way it was. Perhaps it is worth adding that the above *bad* comment was involved in the code for a compiler for a proprietary language which was supposed to be perfectly readable. Those unfamiliar with tha language discovered they could read a program and understand the sequence of steps it represented without being able to tell why they were done. Some well-written comments were still necessary to add that understanding. John Reading readingj@cerf.net ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? [not found] ` <124377@cup.portal.com> 1994-10-11 18:11 ` David Weller 1994-10-11 18:43 ` Robert Dewar @ 1994-10-13 0:51 ` Keith Thompson @pulsar 2 siblings, 0 replies; 43+ messages in thread From: Keith Thompson @pulsar @ 1994-10-13 0:51 UTC (permalink / raw) In <124377@cup.portal.com> R_Tim_Coslet@cup.portal.com writes: > In article: 36v90m$9r4@cmcl2.NYU.EDU> > kenner@lab.ultra.nyu.edu (Richard Kenner) wrote: > >There are actually times when it can! Consider the following fragment > >of an assembler language program for the PDP-11 written by someone who > >was told to write a comment on every line: > > > > ADD #1,R0 ;Add one to R0. > > > >That actually *does* slow down reading! > > > >One company, either DEC (I think) or CDC (less likely) actively > >discouraged this sort of thing in their coding standard. > > Useless comments like that should be BANNED. I agree, but only 99% of the time. Comments should be designed for the enlightenment of the intended audience. In most cases, the intended audience is the person maintaining the code (possibly the original author, possibly someone else), who presumably is fluent in the language being used. If the line appears in chapter 1 of an introduction to PDP-11 assembly language, the comment "Add one to R0" is perfectly appropriate. -- Keith Thompson (The_Other_Keith) kst@alsys.com TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc. 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 /user/kst/.signature: I/O error (core dumped) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-05 3:00 Easily-Read C++? Ken Garlington ` (2 preceding siblings ...) 1994-10-05 17:47 ` Kevin Cline @ 1994-10-05 18:24 ` Magnus Kempe [not found] ` <EACHUS.94Oct6101347@spectre.mitre.org> [not found] ` <1994Oct7.110309@di.epfl.ch> 5 siblings, 0 replies; 43+ messages in thread From: Magnus Kempe @ 1994-10-05 18:24 UTC (permalink / raw) Ada was _designed_ to be readable. C++ is based on C, not something which was designed to be readable (to say the least). Is the code below readable? (pretty standard C++, no?) Try. Read it out, loud. -------------------------------------------------------------- template <class T> class Stack { public: Stack () {size = 0; head = 0;}; ~Stack () {if (head) delete head;}; void push (T& a); void pop (); T& top () {return head->item;}; int count () {return size;}; bool operation== (Stack<T>& a); private: int size; Node<T> *head; }; template <class T> class Node { public: Node (T6 a, Node<T> *b): next(b), item(a) {}; ~Node () {if (next != 0) delete next;}; private: T item; Node<T> *next; friend class stack<T>; }; -------------------------------------------------------------- How does one pronounce "void push (T& a);", or "Node<T> *b", or "{}" ? Do you notice the typos? Compare to a pretty standard Ada 9X equivalent: -------------------------------------------------------------- generic type Item_Type is private; package Stack_G is type Stack_Type is tagged limited private; procedure Push (Stack : in out Stack_Type; Item : in Item_Type); procedure Pop (Stack : in out Stack_Type); function Count (Stack : Stack_Type) return Natural; function Top (Stack : Stack_Type) return Item_Type; operator "=" (Left, Right : Stack_Type) return Boolean; private type Cell_Type; type Link_Type is access cell_Type; type Cell_Type is record Item : Item_Type; Next : Link_Type; end record; type Stack_Type is tagged limited record Size : Natural := 0; Head : Link_Type; end record; end Stack_G; -------------------------------------------------------------- Do you notice the typos? -- Magnus Kempe "I know not what course others may take, but as for me, Magnus.Kempe@di.epfl.ch Give me Liberty... or give me Death!" -- Patrick Henry ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <EACHUS.94Oct6101347@spectre.mitre.org>]
[parent not found: <371a3p$nos@gnat.cs.nyu.edu>]
[parent not found: <1994Oct7.153254.29848@swlvx2.msd.ray.com>]
[parent not found: <374uke$8mo@delphi.cs.ucla.edu>]
[parent not found: <37bno4$ko4@gnat.cs.nyu.edu>]
* Re: Easily-Read C++? [not found] ` <37bno4$ko4@gnat.cs.nyu.edu> @ 1994-10-11 13:00 ` Robert Firth 1994-10-11 13:44 ` Casper H.S. Dik 1994-10-11 18:52 ` Robert Dewar [not found] ` <37eej8$6ie@siberia.gatech.edu> 1 sibling, 2 replies; 43+ messages in thread From: Robert Firth @ 1994-10-11 13:00 UTC (permalink / raw) In article <37bno4$ko4@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes: >An interesting point about the ++ notation is that it appears as far as >I can tell to give undefined results or rather implementation dependent >resultsin the presence of threads, in particular, is it possible for >++c to store a 4 in memory (where there was a 3 before), and then return >6 as a result of rereading c, where intermediate updates have occurred. Unfortunately, as far as I can see this is almost inevitable. The construct expands, semantically, to valof { c := c+1; resultis c } Well, one can try to make the increment an atomic operation, giving, for instance (PE3200 code) LIS R1, 1 ; load 1 into a temp register AM R1, C(RD) ; add it to memory cell C but then you are forced to do another read L R0, C(RD) ; now load new value of C into result reg and, as Robert Dewar mentioned, who knows what has happened in the meantime? The alternative is to make the result computation essentially atomic: L R0, C(RD) ; get value of C into result reg AIS R0, 1 ; add 1 to it and leave as result ST R0, C(RD) ; and store back new value and, again, anything could have happened to the variable C between the read and the write. So the compiler writer, with the best will in the world (a rare quality, I fear) is still pretty much stuck. The C code I've seen is absolutely littered with this stuff. I am continually amazed that *anything* still works when people write true multitasking code in C. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-11 13:00 ` Robert Firth @ 1994-10-11 13:44 ` Casper H.S. Dik 1994-10-11 19:03 ` Robert Dewar 1994-10-12 16:38 ` John DiCamillo 1994-10-11 18:52 ` Robert Dewar 1 sibling, 2 replies; 43+ messages in thread From: Casper H.S. Dik @ 1994-10-11 13:44 UTC (permalink / raw) firth@sei.cmu.edu (Robert Firth) writes: >The C code I've seen is absolutely littered with this stuff. I am >continually amazed that *anything* still works when people write >true multitasking code in C. Why? The only think you need to take care of in C when writing multi-threaded code is using proper (explicit) locking of global data. Most of the foo++ usages in C are of automatic variables. Those aren't shared between threads or even function invocations and consequently there is no problem with c++ kind of code. However, when incrementing a global variable one should do something like this: set_write_lock(foo_lock); foo++; unlock_write_lock(foo_lock); The problem with C multi-threading is making the locking explicit. You may also need to make such variable "volatile" which is C-speak for "can be modified behind my back". Locking is also necessary for reading variables that are shared between threads (and modified by some of those threads). I really don't see what the difference between "foo = foo + 1" or foo++ is in this context. Casper ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-11 13:44 ` Casper H.S. Dik @ 1994-10-11 19:03 ` Robert Dewar 1994-10-12 16:38 ` John DiCamillo 1 sibling, 0 replies; 43+ messages in thread From: Robert Dewar @ 1994-10-11 19:03 UTC (permalink / raw) Casper, you say that shared access to global data requires locking. This plain isn't true, there are all sorts of algorithms that work fine with shared variables. THe purpose of volatile (in either Ada or C/C++) and of atomic in Ada, is precisely to facilitate this kind of usage. Sure in some sense it is cleaner not to use shared variables (in another context we would say it is cleaner not to use global variables, or even, if you are a functional programming fan, that it is cleaner not to use *any* variables). However, both C and Ada recognize that in certain cases, the use of shared variables is useful and legitimate (a bounded buffer with one consumer and one producer is a classical case, see for example the coding of the keyboard buffer in the PC BIOS). THe point is that Ada's definition is considerably more secure that C/C++ here. That's the original point I was making. Ada naturally has to worry about non-sequential semantics, since the standard includes non-sequential execution. In the C standard however, there is no serious consideration of concurrent semantics (that's what I mean by non-sequential here) because the language itself has no such notion. However, lots of C programs do have multiple threads and concurrent execution, and in such contexts, asking what is atomic, and how many times volatile variables are accessed is of semantic significance. Actually even in the absence of concurrent semantics, if a volatile variable refers to a memory mapped I/O location, it may be quite important to know how many times a variable is referenced, since the references may have external semantic effects. Of course a cautious programmer will simply avoid the use of ++mem for such a variable, but it is a little uncomfortable for things to be so ill-defined. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-11 13:44 ` Casper H.S. Dik 1994-10-11 19:03 ` Robert Dewar @ 1994-10-12 16:38 ` John DiCamillo 1 sibling, 0 replies; 43+ messages in thread From: John DiCamillo @ 1994-10-12 16:38 UTC (permalink / raw) casper@fwi.uva.nl (Casper H.S. Dik) writes: >firth@sei.cmu.edu (Robert Firth) writes: >>The C code I've seen is absolutely littered with this stuff. I am >>continually amazed that *anything* still works when people write >>true multitasking code in C. >Why? The only think you need to take care of in C when writing >multi-threaded code is using proper (explicit) locking of global >data. Most of the foo++ usages in C are of automatic variables. >Those aren't shared between threads or even function invocations >and consequently there is no problem with c++ kind of code. >However, when incrementing a global variable one should do something >like this: > set_write_lock(foo_lock); > foo++; > unlock_write_lock(foo_lock); >The problem with C multi-threading is making the locking explicit. >I really don't see what the difference between "foo = foo + 1" >or foo++ is in this context. Actually, in C++ there may be a big difference in readability. Since operator ++ is a function, it can be overridden to include the locking: void f( Protected<Foo>& foo ) { foo++; } The class template Protected wraps the mutation operators in lock()/unlock() pairs to guarantee proper operation in the presence of threads. (Other mutation functions on Foo can not be Pro- tected quite so simply.) -- c'iao, milo ================================================================ John DiCamillo Pinin' for the fjords? milod@netcom.com What kind of talk is that? ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-11 13:00 ` Robert Firth 1994-10-11 13:44 ` Casper H.S. Dik @ 1994-10-11 18:52 ` Robert Dewar 1994-10-12 13:49 ` Norman H. Cohen 1 sibling, 1 reply; 43+ messages in thread From: Robert Dewar @ 1994-10-11 18:52 UTC (permalink / raw) Robert (Firth), you didn't look at my question quite carefully enough. Of course it can be the case that ++c clobbers a value stored by someone else, but I asked the following: is it permissible for ++c to STORE a different value from what it returns? Now of course on all machines, as illustrated by your second code example (which is really the only possibility on all RISC machines, and is the best code on all modern machines), it is possible to generate code so the answer is NO x := x + 1; (x left in a register) (use the value in the register) I would expect that this code is what is generated by most C compilers. The only possible exception is on CISC machines with increment memory or add to memory instructions, when in fact it certainly can answer YES to my question, as illustrated by the first example. Reading the C standard clearly does not answer my question, so we must presume that the two sequences of code have quite a different effect. Note that we ought to assume that the variable involved is volatile, and you would expect that a volatile variable would be accessed in a comprehensible canonical style (this is certainly true in Ada), but the ++c and c++ constructs definitely mean that even if c is volatile you don't know how often it is read and written. I certainly agree with your parting thought! (how can anyone write parallel code in C that is portabl). ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-11 18:52 ` Robert Dewar @ 1994-10-12 13:49 ` Norman H. Cohen 0 siblings, 0 replies; 43+ messages in thread From: Norman H. Cohen @ 1994-10-12 13:49 UTC (permalink / raw) In article <37emsq$smg@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) writes: |> is it permissible for ++c to STORE a different value from what it returns? ... |> Reading the C standard clearly does not answer my question, so we must |> presume that the two sequences of code have quite a different effect. Actually, the C standard clearly indicates that this can happen even in circumstances that do not involve concurrency. The second paragraph of ANSI C section 3.3 (which I think of as the ANSI C answer to Ada RM section 11.6, at least in its ability to keep language lawyers busy trying to interpret it) states: Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value stored.[34] ------- [Footnote 34] This paragraph renders undefined statement expressions such as i = ++i + 1; while allowing i = i + 1; Sequence points are defined syntactically. They include, for example, the points after the evaluation of the left operand of the &&, ||, and comma operators and the ends of statements. The definition appears to me to presume a single-threaded model of execution. I suspect that a large portion of the C code in the field has technically undefined semantics because it violates the quoted paragraph. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <37eej8$6ie@siberia.gatech.edu>]
* Re: Easily-Read C++? [not found] ` <37eej8$6ie@siberia.gatech.edu> @ 1994-10-11 18:55 ` Robert Dewar 1994-10-12 13:35 ` John M. Mills 0 siblings, 1 reply; 43+ messages in thread From: Robert Dewar @ 1994-10-11 18:55 UTC (permalink / raw) John (Mills), I assume that you see from my previous post that the question I posed is indeed a well defined one. I assumed that we are dealing with a volatile variable here, since otherwise all bets are off of course in the presence of concurrent access), but assuming the variable is atomic in the Ada sense (something you can't specify in C, but you can in practice count on, given a reasonable guess about the hardware and the compiler), there is still a fundamental question: how many reads are you allowed, only 1, or are you allowed 2? ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-11 18:55 ` Robert Dewar @ 1994-10-12 13:35 ` John M. Mills 1994-10-12 19:48 ` Robert Dewar 0 siblings, 1 reply; 43+ messages in thread From: John M. Mills @ 1994-10-12 13:35 UTC (permalink / raw) WARNING: long-winded response follows: In article <37en3i$sn7@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote: >John (Mills), I assume that you see from my previous post that the question >I posed is indeed a well defined one. I assumed that we are dealing with >a volatile variable here, since otherwise all bets are off of course in >the presence of concurrent access), but assuming the variable is atomic in >the Ada sense (something you can't specify in C, but you can in practice >count on, given a reasonable guess about the hardware and the compiler), >there is still a fundamental question: how many reads are you allowed, >only 1, or are you allowed 2? DISCLAIMER: I am not a qualified language lawyer in either C or Ada! Robert -- I apologize for missing the thrust of your posting. I understand that C defines the precedence, but not necessarily the order of evaluation of elements of an r-value expression, so that implementation dependencies may be encountered in using the unary ++ and -- pre- and post-fix operators. Thus, I would not use an expression such as: y = ++x + x; This is independent of the issue of parallel processes, whether interrupt- activated or threaded. I do not know whether judicious use of parentheses can eliminate possible dependencies, either. If the variable is declared 'volatile,' I would expect the compiler to read the storage location each time I used the variable name in an expression or control statement. I would expect this is in Ada or C. I don't know if this removes all ambiguity in the case, for example, of a pointer-referenced access. (See DISCLAIMER.) Were you suggesting that one thread of C code might intercede during the evaluation of an expression on another thread? Does Ada guarantee this would never happen? I am unsure what distinction you want to make here. I took a quick look at the LRM index, but didn't turn up 'atomic.' Please clue me on that. Thanks. We often use common variables and memory-mapped I/O in Ada to communicate between tasks and between independent programs running on multiple processors on a common VME bus. We have had task-to-task interference in such cases, on one processor. In that case we could have used the rendezvous mechanism to arbitrate the activity, but instead we created a lock/unlock package which seems to work well. I couldn't guarantee it immune to deadlock, but it _will_ prevent invisible alteration of data by a competing task. This could be rewritten and used in C -- there's nothing special in our Ada. I am quite interested in this question, as we encounter competitive access fairly often in our designs. We have taken the proverbial approach of porcupines to sexual intercourse: we are very, _very_ careful! I have been burned many times by this type of contention, and the most recent case was in Ada. I may still be missing the point. If so, please excuse me and feel free to try another tack -- maybe e-mail, since I'm rather obtuse. Regards --jmm-- -- John M. Mills, SRE -- john.m.mills@gtri.gatech.edu -- (404)528-3258 (voice) Georgia Tech/ GTRI/ SDL, 7220 Richardson Rd., Smyrna, GA 30080 "Well, I'm an Assistant Regurgitation Engineer -- but I should make Senior R.E. next year" _The_Far_Side_, G. Larson ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-12 13:35 ` John M. Mills @ 1994-10-12 19:48 ` Robert Dewar 0 siblings, 0 replies; 43+ messages in thread From: Robert Dewar @ 1994-10-12 19:48 UTC (permalink / raw) atomic is certainly listed in my LRM index (we *are* talking Ada 9X here, so I am talking about the 9X 5.0 RM). If you want to talk Ada 83, then pragma Shared serves the purpose of pragma Volatile and pragma Atomic rolled into one (9X sensibly separates these concerns). Obviously if you write: x = x + 1; in either language, you know EXACTLY the meaning if x is atomic and volatile. Sure some other thread can come in, but the exact range of possible effects is well understood, and for example, you can easily implement Djkstra's semaphore algorithm to get coordination of two processes without any explicit system level communication or rendez-vous etc. I am not particularly suggesting you want to do this, but you can. Now if in C, we replace this with: ++x; then we really are not quite sure what that means. No one thinks it means that you can only reference x once, because unless you are on a specialized machine with a fetch-and-add (like the x86), then there is no instruction or instruction sequence that can achieve this in one reference. So, is it the case (remembering that x is volatile and atomic) that there can be at most two references? Well that seems a possible reasonable thing to say, but there is nowhere in the C reference manual that you can deduce such a rule. I trust that makes this clear, or at least clearer. ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <CxFr5B.K1G@news.otago.ac.nz>]
[parent not found: <DAG.94Oct10075533@bellman.control.lth.se>]
* Re: Easily-Read C++? [not found] ` <DAG.94Oct10075533@bellman.control.lth.se> @ 1994-10-11 17:50 ` Norman H. Cohen 0 siblings, 0 replies; 43+ messages in thread From: Norman H. Cohen @ 1994-10-11 17:50 UTC (permalink / raw) In article <DAG.94Oct10075533@bellman.control.lth.se>, dag@control.lth.se (Dag Bruck) writes: |> I may be worth pointing out that the C++ standard will provide some |> additional tokens, e.g.: |> |> and <=> && |> or <=> || |> not <=> ! |> |> bitand <=> & |> bitor <=> | |> xor <=> ^ |> |> I think C users can get a similar effect by including iso646.h. |> |> Gee! The world is changing. Indeed. Now General Whittaker will be able to key in C++ programs on his keypunch. :-) -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <373vd2$39n@theopolis.orl.mmc.com>]
[parent not found: <CxBvq7.GrH@inmet.camb.inmet.com>]
[parent not found: <37bnic$kj2@gnat.cs.nyu.edu>]
* Re: Easily-Read C++? [not found] ` <37bnic$kj2@gnat.cs.nyu.edu> @ 1994-10-11 18:02 ` Norman H. Cohen 0 siblings, 0 replies; 43+ messages in thread From: Norman H. Cohen @ 1994-10-11 18:02 UTC (permalink / raw) In article <37bnic$kj2@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) writes: |> One little addition on min and max, they are static attributes and so can |> be used in static expressions. That's quite useful.... I agree. I only wish there were a way--short of writing Largest_Integer_Type'Pos(Largest_Integer_Type'Max(...,...))--to use 'Max and 'Min in universal expressions. In fact, even this doesn't work for real numbers. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <1994Oct7.110309@di.epfl.ch>]
[parent not found: <DAG.94Oct7204142@bellman.control.lth.se>]
[parent not found: <1994Oct7.210111.4494@nosc.mil>]
[parent not found: <374i3o$c87@Starbase.NeoSoft.COM>]
* Re: "Tag" (Was: Easily-Read C++? (NOT)) [not found] ` <374i3o$c87@Starbase.NeoSoft.COM> @ 1994-10-12 17:37 ` David Emery 0 siblings, 0 replies; 43+ messages in thread From: David Emery @ 1994-10-12 17:37 UTC (permalink / raw) Ah, yes, a reading from the Gospel according to Tucker... dave -- --The preceeding opinions do not necessarily reflect the opinions of --The MITRE Corporation or its sponsors. -- "A good plan violently executed -NOW- is better than a perfect plan -- next week" George Patton -- "Any damn fool can write a plan. It's the execution that gets you -- all screwed up" James Hollingsworth ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <3719k1$11gt@watnews1.watson.ibm.com>]
[parent not found: <85C92963672@annwfn.com>]
* Re: Easily-Read C++? [not found] ` <85C92963672@annwfn.com> @ 1994-10-11 18:37 ` Norman H. Cohen 1994-10-12 16:54 ` David Emery 0 siblings, 1 reply; 43+ messages in thread From: Norman H. Cohen @ 1994-10-11 18:37 UTC (permalink / raw) In article <85C92963672@annwfn.com>, merlin@annwfn.com (Fred McCall) writes: |> In <3719k1$11gt@watnews1.watson.ibm.com> ncohen@watson.ibm.com Norman H. Cohen writes: ... |> > |> >A more substantive objection to C++ is the fragility of programs written |> >in the language. Over and over again in the Annotated C++ Reference |> >Manual we see the phrase "You are warned," as if that shifts all |> >responsibility for an error-prone construct from the language designer to |> >the programmer who falls into the trap that has been set for him. |> |> Well, that's no worse than needing a copy of the Standard to be able to |> figure out what the hell Ada should be doing in a given situation. 1. It IS worse. The C++ rule makes it easy for a simple clerical error to corrupt the data structures of the run-time system. 2. The insinuation in this strange comparison is false. Every language has rules whose details have to be looked up now and then, but most of the time an Ada progammer does NOT "need a copy of the Standard to be able to figure out what the hell Ada should be doing in a given situation." |> >For example, the C++ type system (inherited from C) does not distinguish |> >between a pointer to an array of type T and a pointer to an individual |> >object of type T. |> |> Well, if you're not bright enough to keep the single fact in mind that |> arrays are not first class types in C (or C++), then you have a point. The problem is not in UNDERSTANDING that C does not distinguish between pointer-to-T and pointer-to-array-of-T, it is in coping with that language deficiency. The fact of the matter is that C++ allocators and delete statements DO distinguish between the two in their run-time behavior, so that a two-character clerical error has disastrous results; but the C/C++ type system does NOT distinguish between the two at compile time, so this error cannot, in general, be caught by the compiler. |> You should seek a safer language. Ada is not going to be safe enough |> for you, either. I'd suggest something using rubber letters. Programming with the Goodyear blimp is overkill. Type-safe deallocation, as provided in Ada by strongly-typed instantiations of Unchecked_Deallocation, is quite sufficient, thank you. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-11 18:37 ` Easily-Read C++? Norman H. Cohen @ 1994-10-12 16:54 ` David Emery 1994-10-14 21:13 ` Kevin Cline 0 siblings, 1 reply; 43+ messages in thread From: David Emery @ 1994-10-12 16:54 UTC (permalink / raw) The ambiguity 'inherent' in declarations such as char * foo; char ** foo; char foo[]; char *foo[]; causes problems for C tools. Even though each of the above is 'unambiguous', common usage means that any of these can be used to represent the others. At least one tool I know of (an RPC generator for C) requires the user to disambiguate some of the above declarations, to make sure that the tool generates the right code. What's bad for tools is certainly bad for programmers.... dave -- --The preceeding opinions do not necessarily reflect the opinions of --The MITRE Corporation or its sponsors. -- "A good plan violently executed -NOW- is better than a perfect plan -- next week" George Patton -- "Any damn fool can write a plan. It's the execution that gets you -- all screwed up" James Hollingsworth ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-12 16:54 ` David Emery @ 1994-10-14 21:13 ` Kevin Cline 1994-10-21 14:38 ` Thomas M. Breuel 0 siblings, 1 reply; 43+ messages in thread From: Kevin Cline @ 1994-10-14 21:13 UTC (permalink / raw) In article <EMERY.94Oct12165432@goldfinger.mitre.org>, emery@goldfinger.mitre.org (David Emery) writes: |> The ambiguity 'inherent' in declarations such as |> char * foo; |> char ** foo; |> char foo[]; |> char *foo[]; |> causes problems for C tools. Even though each of the above is |> 'unambiguous', common usage means that any of these can be used to |> represent the others. At least one tool I know of (an RPC generator |> for C) requires the user to disambiguate some of the above |> declarations, to make sure that the tool generates the right code. |> These declarations are not equivalent. The first is equivalent to the third, and the second to the fourth. The equivalence of C pointers and arrays is unfortunate. It is maintained by C++ for backward compatibility reasons. Most C++ applications use a library template array class instead of C arrays. Kevin Cline ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-14 21:13 ` Kevin Cline @ 1994-10-21 14:38 ` Thomas M. Breuel 1994-10-22 3:10 ` Michael M. Bishop 0 siblings, 1 reply; 43+ messages in thread From: Thomas M. Breuel @ 1994-10-21 14:38 UTC (permalink / raw) In article <CxoLLu.Av3@uunet!aadt> a311581@ventures.NoSubdomain.NoDomain (Kevin Cline) writes: |In article <EMERY.94Oct12165432@goldfinger.mitre.org>, emery@goldfinger.mitre.org (David Emery) writes: ||> The ambiguity 'inherent' in declarations such as ||> char * foo; ||> char ** foo; ||> char foo[]; ||> char *foo[]; ||> causes problems for C tools. Even though each of the above is ||> 'unambiguous', common usage means that any of these can be used to ||> represent the others. At least one tool I know of (an RPC generator ||> for C) requires the user to disambiguate some of the above ||> declarations, to make sure that the tool generates the right code. ||> |These declarations are not equivalent. The first is equivalent to the third, |and the second to the fourth. | |The equivalence of C pointers and arrays is unfortunate. It is maintained |by C++ for backward compatibility reasons. Most C++ applications use |a library template array class instead of C arrays. None of those declarations are equivalent (if people want to criticize C, they should at least have a basic understanding of it!). Furthermore, the problem that RPC systems have with C is that arrays and pointers do not carry bounds information with them. (Another problem is that C pointers can point to heap data, into the middle of other data structures, or to stack data.) That is indeed a problem in some situations, but it is not related to declaration syntax. On the other hand, real-world users will probably not accept a language that doesn't provide some equivalent of C's plain arrays: the overhead of carrying bounds information around at runtime is sometimes unacceptable. In C++, none of this is a problem: arrays usually carry bounds information (static or dynamic) and can easily be serialized for RPC. C-style arrays need only be used in very specific situations. Thomas. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-21 14:38 ` Thomas M. Breuel @ 1994-10-22 3:10 ` Michael M. Bishop 1994-10-26 0:39 ` -mlc-+Schilling J. 0 siblings, 1 reply; 43+ messages in thread From: Michael M. Bishop @ 1994-10-22 3:10 UTC (permalink / raw) In article <TMB.94Oct21153826@arolla.idiap.ch>, Thomas M. Breuel <tmb@idiap.ch> wrote: >That is indeed a problem in some situations, but it is not related to >declaration syntax. On the other hand, real-world users will probably >not accept a language that doesn't provide some equivalent of C's >plain arrays: the overhead of carrying bounds information around at >runtime is sometimes unacceptable. You don't have to carry Ada array bounds information around at run-time. You can use the pragma Suppress to remove those checks from the generated object code. In fact, I believe that this is often done in real-world applications. When building the system for the production environment, the pragma is added. I know that this is nitpicking given the context of this thread, but this is what I do when I have nothing of substance to add to the conversation :-). -- | Mike Bishop | The opinions expressed here reflect | | bishopm@source.asset.com | those of this station, its management, | | Member: Team Ada | and the entire world. | ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-22 3:10 ` Michael M. Bishop @ 1994-10-26 0:39 ` -mlc-+Schilling J. 1994-10-27 14:54 ` Bob Duff 0 siblings, 1 reply; 43+ messages in thread From: -mlc-+Schilling J. @ 1994-10-26 0:39 UTC (permalink / raw) In article <389vqv$i6n@source.asset.com> bishopm@source.asset.com (Michael M. Bishop) writes: >In article <TMB.94Oct21153826@arolla.idiap.ch>, Thomas M. Breuel <tmb@idiap.ch> wrote: >>On the other hand, real-world users will probably >>not accept a language that doesn't provide some equivalent of C's >>plain arrays: the overhead of carrying bounds information around at >>runtime is sometimes unacceptable. > >You don't have to carry Ada array bounds information around at run-time. >You can use the pragma Suppress to remove those checks from the >generated object code. Pragma Suppress doesn't relate to carrying around array bounds at runtime, but rather to whether index checks are done. If the array bounds are dynamic, then it is necessary to carry them around in order to generate correct indexing offset code, whether or not you are also doing the checks. But more to the original point, if Ada arrays are declared as equivalents of C's plain arrays, then the bounds will be static and they will _not_ be carried around at runtime. (The bounds will materialise if you pass the array to an unconstrained formal, but this happens to some extent in C as well - typically you pass in both the beginning and ending addresses of an array.) -- Jonathan Schilling Novell, UNIX Systems Group jls@summit.novell.com ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-26 0:39 ` -mlc-+Schilling J. @ 1994-10-27 14:54 ` Bob Duff 1994-10-27 15:35 ` Richard Kenner ` (2 more replies) 0 siblings, 3 replies; 43+ messages in thread From: Bob Duff @ 1994-10-27 14:54 UTC (permalink / raw) In article <38k8g2INNiff@marble.summit.novell.com>, -mlc-+Schilling J. <jls@summit.novell.com> wrote: >Pragma Suppress doesn't relate to carrying around array bounds at runtime, >but rather to whether index checks are done. If the array bounds are >dynamic, then it is necessary to carry them around in order to generate >correct indexing offset code, whether or not you are also doing the checks. I don't think that's quite right. The compiler can always store the address of the zero-th element (even if there is no such element), and then the indexing calculation doesn't need to subtract the lower bound. Thus, if checks are suppressed, there should be no need to store the bounds. On the other hand, if there are any whole-array assignments, then the size has to be stored (or some information from which the size can be calculated). I don't know how many compilers use zero-based arrays. I believe GNAT does. I don't know how many compilers are clever enough to make pragma Suppress not only suppress the checking code, but also the data necessary to perform the checks. It could get tricky, especially in the presence of separate compilation. - Bob -- Bob Duff bobduff@inmet.com Oak Tree Software, Inc. Ada 9X Mapping/Revision Team (Intermetrics, Inc.) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-27 14:54 ` Bob Duff @ 1994-10-27 15:35 ` Richard Kenner 1994-10-27 23:09 ` Robert Dewar 1994-11-01 21:19 ` Adam Beneschan 2 siblings, 0 replies; 43+ messages in thread From: Richard Kenner @ 1994-10-27 15:35 UTC (permalink / raw) In article <CyC6rB.JLr@inmet.camb.inmet.com> bobduff@dsd.camb.inmet.com (Bob Duff) writes: >I don't know how many compilers use zero-based arrays. I believe GNAT >does. Not yet, though it is our intent to do so and we have set up our fat pointer mechanism to make this easier. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-27 14:54 ` Bob Duff 1994-10-27 15:35 ` Richard Kenner @ 1994-10-27 23:09 ` Robert Dewar 1994-11-01 21:19 ` Adam Beneschan 2 siblings, 0 replies; 43+ messages in thread From: Robert Dewar @ 1994-10-27 23:09 UTC (permalink / raw) Bob Duff guesses that if you store virtual origins and suppress checks you do not need to pass bounds around. It's tricky, since we intend in GNAT to use virtual origins at some point (it is exactly why we use "fat" pointers for unconstrained types), we have looked into this issue in some detail. The trouble is that there are a number of subsidiary language features that will require the bounds ('Address, 'Access, passing array to a foreign routine ...) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-10-27 14:54 ` Bob Duff 1994-10-27 15:35 ` Richard Kenner 1994-10-27 23:09 ` Robert Dewar @ 1994-11-01 21:19 ` Adam Beneschan 1994-11-02 0:46 ` Bob Duff 2 siblings, 1 reply; 43+ messages in thread From: Adam Beneschan @ 1994-11-01 21:19 UTC (permalink / raw) bobduff@dsd.camb.inmet.com (Bob Duff) writes: > In article <38k8g2INNiff@marble.summit.novell.com>, > -mlc-+Schilling J. <jls@summit.novell.com> wrote: > >Pragma Suppress doesn't relate to carrying around array bounds at runtime, > >but rather to whether index checks are done. If the array bounds are > >dynamic, then it is necessary to carry them around in order to generate > >correct indexing offset code, whether or not you are also doing the checks. > > I don't think that's quite right. The compiler can always store the > address of the zero-th element (even if there is no such element), and > then the indexing calculation doesn't need to subtract the lower bound. > Thus, if checks are suppressed, there should be no need to store the > bounds. > > On the other hand, if there are any whole-array assignments, then the > size has to be stored (or some information from which the size can be > calculated). Also, if you use the 'FIRST, 'LAST, 'RANGE, or 'LENGTH attributes, you will need to carry the bounds. Otherwise the following can't be compiled: pragma SUPPRESS (ALL_CHECKS); type INT_ARRAY is array (NATURAL range <>) of INTEGER; function SUM (A : INT_ARRAY) return INTEGER is RESULT : INTEGER; begin RESULT := 0; for I in A'RANGE loop RESULT := RESULT + A(I); end loop; return RESULT; end SUM; I suppose that your suggestion will work if the *only* operation you perform on a dynamic one-dimensional array is indexing, but quite frankly I can't imagine anyone wanting to write a routine that takes a dynamic array, uses only indexing, and doesn't use 'FIRST, 'LAST, or 'RANGE (or pass the array on to another routine that does). Also, it should be noted that your suggestion won't work on dynamic two-dimensional or higher-dimensional arrays. -- Adam ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++? 1994-11-01 21:19 ` Adam Beneschan @ 1994-11-02 0:46 ` Bob Duff 0 siblings, 0 replies; 43+ messages in thread From: Bob Duff @ 1994-11-02 0:46 UTC (permalink / raw) In article <CyLxwF.7LK@irvine.com>, Adam Beneschan <adam@irvine.com> wrote: >I suppose that your suggestion will work if the *only* operation you >perform on a dynamic one-dimensional array is indexing, but quite >frankly I can't imagine anyone wanting to write a routine that takes a >dynamic array, uses only indexing, and doesn't use 'FIRST, 'LAST, or >'RANGE (or pass the array on to another routine that does). Yes, you are correct. It is interesting to think about when a compiler could store just, say, the address of the first element and the length (and calculate everything else from that). Super-null arrays cause trouble: X: String(100 .. -12345); The length is zero, but Ada requires one to remember the actual bounds, at least in some circumstances. >Also, it should be noted that your suggestion won't work on dynamic >two-dimensional or higher-dimensional arrays. Correct. In the multi-dimensional case, the indexing calculation depends on the size of the lower dimensions. - Bob -- Bob Duff bobduff@inmet.com Oak Tree Software, Inc. Ada 9X Mapping/Revision Team (Intermetrics, Inc.) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++ @ 1994-10-12 3:06 Ken Garlington 0 siblings, 0 replies; 43+ messages in thread From: Ken Garlington @ 1994-10-12 3:06 UTC (permalink / raw) Fred McCall <merlin@ANNWFN.COM> writes: << Most of us don't expect people to understand what we write unless they speak the language, not to mention that only trivial Ada programs are so easily read and understood. >> Wrong on both counts. I want people with very little language training or even software engineering training (if any) to quickly understand the algorithms and data structures I'm defining. This includes hardware engineers, system test engineers, IIV&V, SQA, System Safety, etc. I want them to be able to understand those programs, even if they are 50K source lines of code or more. Ada works very well for this purpose. Does C++? Sounds like it's a non-issue, since C++ programmers only write for themselves and their fellow programmers. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Easily-Read C++?
@ 1994-10-14 10:50 Bob Wells #402
0 siblings, 0 replies; 43+ messages in thread
From: Bob Wells #402 @ 1994-10-14 10:50 UTC (permalink / raw)
Robert Dewar <dewar@CS.NYU.EDU> writes .....
> Subject: Re: Easily-Read C++?
>
> There are to my mind three justifications for comments:
>
> Saying WHY you are doing something, and WHY you did it that way
>
> Saying WHY you did NOT do something, and WHY you did NOT
>
> Describing WHAT the code does, but at a higher level of abstraction
> than the code itself.
G'day Robert,
I totally agree with the above justifications and would also add the
following two:
Describing assumptions about the format or structure of an external
interface, e.g. an incoming message.
-- STAMINA message originator format
-- ORIG/ROLE/HQ
Describing the corresponding meaning for values when they are
defined. For example.
-- The following corresponds to the field RBT in the STORE.QTID section of
-- the PEAQTID file when the TYP field contains a 1 and RBN /= 0.
--
type Rlb_Data is ( Sdd_Coordinates,
Plot_Identification,
Track_Identification,
Sdd_Test_Picture_Display,
Track_Id_Or_System_Coordinates,
System_Coordinates,
Ssr_Code );
Regards,
Bob W. (-:
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~1994-11-02 0:46 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1994-10-05 3:00 Easily-Read C++? Ken Garlington 1994-10-05 9:42 ` Pierre Castori 1994-10-05 13:28 ` Robert Dewar 1994-10-06 2:20 ` Benjamin Ketcham [not found] ` <CxDL8H.KGE@csn.org> [not found] ` <milodCxH2E4.7F4@netcom.com> [not found] ` <CxHJv0.Kw0@csn.org> 1994-10-12 17:03 ` John DiCamillo [not found] ` <DAG.94Oct11080229@bellman.control.lth.se> [not found] ` <37du0k$ir2@gnat.cs.nyu.edu> 1994-10-12 3:19 ` Attractive comments better? R_Tim_Coslet 1994-10-13 1:35 ` Michael Feldman 1994-10-05 14:26 ` Easily-Read C++? Eric S. Sessoms 1994-10-05 17:47 ` Kevin Cline 1994-10-05 22:02 ` Robert Dewar 1994-10-05 22:23 ` Richard Kenner [not found] ` <124377@cup.portal.com> 1994-10-11 18:11 ` David Weller 1994-10-11 18:43 ` Robert Dewar 1994-10-12 13:15 ` Norman H. Cohen 1994-10-12 14:10 ` Robert Firth 1994-10-13 19:33 ` John D. Reading 1994-10-13 0:51 ` Keith Thompson @pulsar 1994-10-05 18:24 ` Magnus Kempe [not found] ` <EACHUS.94Oct6101347@spectre.mitre.org> [not found] ` <371a3p$nos@gnat.cs.nyu.edu> [not found] ` <1994Oct7.153254.29848@swlvx2.msd.ray.com> [not found] ` <374uke$8mo@delphi.cs.ucla.edu> [not found] ` <37bno4$ko4@gnat.cs.nyu.edu> 1994-10-11 13:00 ` Robert Firth 1994-10-11 13:44 ` Casper H.S. Dik 1994-10-11 19:03 ` Robert Dewar 1994-10-12 16:38 ` John DiCamillo 1994-10-11 18:52 ` Robert Dewar 1994-10-12 13:49 ` Norman H. Cohen [not found] ` <37eej8$6ie@siberia.gatech.edu> 1994-10-11 18:55 ` Robert Dewar 1994-10-12 13:35 ` John M. Mills 1994-10-12 19:48 ` Robert Dewar [not found] ` <CxFr5B.K1G@news.otago.ac.nz> [not found] ` <DAG.94Oct10075533@bellman.control.lth.se> 1994-10-11 17:50 ` Norman H. Cohen [not found] ` <373vd2$39n@theopolis.orl.mmc.com> [not found] ` <CxBvq7.GrH@inmet.camb.inmet.com> [not found] ` <37bnic$kj2@gnat.cs.nyu.edu> 1994-10-11 18:02 ` Norman H. Cohen [not found] ` <1994Oct7.110309@di.epfl.ch> [not found] ` <DAG.94Oct7204142@bellman.control.lth.se> [not found] ` <1994Oct7.210111.4494@nosc.mil> [not found] ` <374i3o$c87@Starbase.NeoSoft.COM> 1994-10-12 17:37 ` "Tag" (Was: Easily-Read C++? (NOT)) David Emery [not found] <3719k1$11gt@watnews1.watson.ibm.com> [not found] ` <85C92963672@annwfn.com> 1994-10-11 18:37 ` Easily-Read C++? Norman H. Cohen 1994-10-12 16:54 ` David Emery 1994-10-14 21:13 ` Kevin Cline 1994-10-21 14:38 ` Thomas M. Breuel 1994-10-22 3:10 ` Michael M. Bishop 1994-10-26 0:39 ` -mlc-+Schilling J. 1994-10-27 14:54 ` Bob Duff 1994-10-27 15:35 ` Richard Kenner 1994-10-27 23:09 ` Robert Dewar 1994-11-01 21:19 ` Adam Beneschan 1994-11-02 0:46 ` Bob Duff -- strict thread matches above, loose matches on Subject: below -- 1994-10-12 3:06 Easily-Read C++ Ken Garlington 1994-10-14 10:50 Easily-Read C++? Bob Wells #402
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox