rich@inmet.inmet.com (06/16/90)
To try to clarify these discussions about the // comments, I think the question is what the phases of translation in the preprocessor are. In ANSI C, the phases are: 1. terminates each line w/ a '\n' 2. converts trigraphs 3. concatenates lines ended w/ \ '\n' w/ their following line 4. replace comments (exception: string, std header) w/ a space 5. carry out directives 5. expand macros in non-skipped lines ...etc I think it is cleaner to treat // comment in phase 4. That way the \ '\n' semantic is the same everywhere. Also, if we treat // comment exactly the same as /* */ comment, it also answers the question what happen in the following case: #define foo bar // gibberish foo is this part of the line? If we take care of // in phase four and replace it w/ a space, then "is this.." is indeed part of the line. Richard Man rich@inmet.inmet.com
jar@io.UUCP (Jim Roskind x5570) (06/16/90)
> > Jun 15 15:42:00 1990 Richard Man inmet.inmet.com!rich writes: > > To try to clarify these discussions about the // comments, I think the question > is what the phases of translation in the preprocessor are. In ANSI C, the > phases are: > > 1. terminates each line w/ a '\n' > 2. converts trigraphs > 3. concatenates lines ended w/ \ '\n' w/ their following line > 4. replace comments (exception: string, std header) w/ a space I would say "4. Tokenize, which includes replacing comments....". > 5. carry out directives > 5. expand macros in non-skipped lines > ...etc > > I think it is cleaner to treat // comment in phase 4. I agree whole heartedly only up to this point. There are already enough independent phases of preprocessing translation to keep track of, and I would not like to see any others introduced. I would also *NOT* like to see // style comments isolated in any phase that was not already tokenizing. > That way the \ '\n' > semantic is the same everywhere. Also, if we treat // comment exactly the > same as /* */ comment, it also answers the question what happen in the following > case: > #define foo bar // gibberish > foo is this part of the line? > > If we take care of // in phase four and replace it w/ a space, then "is this.." > is indeed part of the line. > > Richard Man rich@inmet.inmet.com I disagree. I think there are two simple choices for a standard: 1) A // based comment *DOES*NOT* terminate a directive line. OR 2) A // based comment terminates a directive line, exactly as does a '\n'. IMHO the // comment syntax was introduced to provide a comment with *VERY* local impact. Specifically, it was intended that you would not have to concern yourself with the termination point of the comment. For example, I would like to write code like: #define foo goo // use this only at file scope #define FOO who // use this only at block scope ***IF**** alternative 2 was standardized, as suggested by, among others, Richard Man, then I would be forced to write code like: #define foo goo /* use this only at file scope */ #define FOO who /* use this only at block scope */ and I would once again begin to desire a comment that did not require a terminator (presumably, because I sometimes forget to provide the terminator, which induces nasty bugs). I believe that the two options are *EQUALLY* well defined, but the first provides utility that is more in keeping with rationale for extending the C language with the construct. Bottom line: // style comments *SHOULD* terminate preprocessing directives. Jim Roskind jar@ileaf.com ...!uunet!leafusa!jar (407)729-4348 or (617)577-9813 x5570 -- Jim Roskind Independent Consultant (407)729-4348 or (617)577-9813 x5570 jar@ileaf.com or ...!uunet!leafusa!jar
mckenney@sparkyfs.istc.sri.com (Paul Mckenney) (06/29/90)
In article <804@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >In article <1580@io.UUCP> jar@io.UUCP (Jim Roskind x5570) writes: >>> >>> Jun 15 15:42:00 1990 Richard Man inmet.inmet.com!rich writes: >>> >[about // comments] >Though I don't have practical experience with C++, I know about its >key features. The idea of //-comments allways appealed to me, but I >can't see why they are so problematic. (Well, I see that there may >arise problems from a theoretical point of view.) >IMHO such comments should modell the expectations of the majority of >users (ie. programmers). Now, what *are* the expectations of the >majority? I suspect that the majority of users need not deal with multi-line macros often, and I hope that the fraction of users that must work with such things declines sharply once templates become available. The problems with //-comments only appear in conjuntion with continuation lines, which are needed mostly for multiline macros (they are no longer needed for multiline strings). So I would expect that the majority of programmers would be satisfied with any of the solutions that have been advanced. >This questions turns out to have a simple answer (again "IMHO", of >course :-)): >Many of us work not only with C, but also with the UNIX SHELL, AWK, >MAKE, ... and there *are* exactly such comments in all these programs >(except that they start with '#'). The manual tells that such comments >terminate at the end of line, but they *don't* say that the Newline is >*discarded* (in fact, it isn't). I agree that this is the way these tools handle such comments, but I have the same objection to it as I do to the way C++ handles //-comments. If I have a long, multiline command in an ``sh'' script, I cannot comment parts of the command -- any comment I supply will terminate the command. This behavior is especially annoying when I need to use complex commands with obscure syntax such as ``find''. ``awk'' does not pose so much of a problem, as multiline commands can usually be broken down into single-line commands through use of temporaries or loop-exit constructs. Then comments may be placed between the resulting separate statements without problems. ``make'' ends up working well, perhaps by accident... Escaped newlines are needed to allow if's and for's in the shell commands. Comments that appear on the ends of these lines are passed uninterpreted to ``sh'', but after the backslashes have been stripped. Thus, these comments do not interfere with the continuation. >If I use any of the above tools a `#......Newline'-comment would never >introduce a continuation line. So it shouldn't do so in C++ -- or it will >counter-intuitive to all with only slight experience from Unix tools. People with only slight experience with these tools have most likely not been so unfortunate as to run into a situation where it makes a difference (IMHO, of course!). C++ follows ANSI C in its definition of phases of compilation. Unfortunately, ANSI C does not have //-style comments, so this results in a less-than-useful interaction between //-style comments and continuation lines. Thanx, Paul
steve@taumet.com (Stephen Clamage) (06/29/90)
I am mystified by the continuing arguments in this thread. The semantics of allowing //-comments to go to the end of the line except when they don't go to the end of the line seem pretty strange to me. C++ does still have /*...*/ comments, please recall, and this comment form does precisely what is wanted without requiring odd semantic interpretations. So if you must use complex macros in C++, and if you must have internal comments in them, just use /*...*/ comments. This always has worked and always will work. I dunno. Maybe I'm too simple-minded. -- Steve Clamage, TauMetric Corp, steve@taumet.com
mckenney@sparkyfs.istc.sri.com (Paul Mckenney) (07/05/90)
In article <278@taumet.com> steve@taumet.UUCP (Stephen Clamage) writes: >I am mystified by the continuing arguments in this thread. The semantics >of allowing //-comments to go to the end of the line except when they >don't go to the end of the line seem pretty strange to me. C++ does >still have /*...*/ comments, please recall, and this comment form does >precisely what is wanted without requiring odd semantic interpretations. >So if you must use complex macros in C++, and if you must have internal >comments in them, just use /*...*/ comments. This always has worked >and always will work. //-comments are currently defined (Ellis & Stroustrup) to go to the end of the line, except when they go past the end of the line. This seems quite strange to me. In constrast, having the effect of a //-comment end just before the first subsequent newline or escaped newline seems quite simple and natural. It preserves a major advantage of the //-comment -- the end of the comment is immediately obvious; the human reader need never painfully scrutinize the code to find out where the comment ends. Of course, I -could- use /*...*/ comments exclusively. I do use them for large boxed comments, mostly because I have templates for these from years of C programming. I also use them inside of the occasional large, complex macro, since I have no real choice (I refuse to leave such macros uncommented!!!). However, I much prefer the //-comments, and am very happy that they are in the language. I just wish that they were better integrated. >I dunno. Maybe I'm too simple-minded. Or maybe I am expecting too much gratuitous consistency and ease of use. Thanx, Paul