kevinb@maccs.dcss.mcmaster.ca (Kevin Boyes) (12/14/90)
Does any one know why the ANSI committee excluded the C++ comment style ( // to end of line ) from the standard. K. -- -- Kevin Boyes kevinb@maccs.McMaster.CA McMaster University ...!uunet!utai!utgpu!maccs!kevinb
sef@kithrup.COM (Sean Eric Fagan) (12/21/90)
In article <276814F4.141@maccs.dcss.mcmaster.ca> kevinb@maccs.dcss.mcmaster.ca (Kevin Boyes) writes: >Does any one know why the ANSI committee excluded the C++ comment style >( // to end of line ) from the standard. Show me a C compiler that implements this. (Actually, Microsoft C 5.0 and later does.) Show me a need for it. (Prototypes fulfilled a rather large hole, and made life a *lot* easier for certain groups.) Adding // comments was, for the most part, untested in C, and unnecessary. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jdb@reef.cis.ufl.edu (Brian K. W. Hook) (12/21/90)
I personally like the // commenting style. Including it would not have been a major hassle for the ANSI committee, I beleive. It is very nice and quite quick when it comes to commenting out only one line of code. No going to end of line and adding a */...that gets annoying. for large blocks of code, I prefer the /* */ combination, and I also prefer it for "real" comments, ie. permanent programmer-programmer comments, not just temporarily stopping the compilation of a routine. By the way, // is supported by TC++ even when it is in .C compile mode only. Brian
iverson@ivy.uucp (Tim Iverson) (12/28/90)
In article <26036@uflorida.cis.ufl.EDU> jdb@reef.cis.ufl.edu (Brian K. W. Hook) writes: >I personally like the // commenting style. Including it would not have been >a major hassle for the ANSI committee, I beleive. It is very nice and quite >quick when it comes to commenting out only one line of code. No going to >end of line and adding a */...that gets annoying. [...] Actually, you don't have to put the closing '*/' on the *end* of the line: /* e.g. these lines are commented out /* even if they have comments */ /* You can also grep for "^/**/" to find where they all are. /**/ >Brian - Tim Iverson uunet!xstor!iverson
mcdaniel@adi.com (Tim McDaniel) (12/29/90)
iverson@ivy.uucp (Tim Iverson) screwed up, I'm afraid.
#include <stdio.h>
/* e.g. these lines are commented out /* even if they have comments */
/* You can also grep for "^/**/" to find where they all are.
/**/
main() { printf("Hello world\n"); exit(0); }
gcc -Wall -ansi -pedantic 72.c
72.c:2: warning: `/*' within comment
72.c:3: warning: `/*' within comment
72.c:3: unterminated string or character constant
The `*/' on line 3 ends the comment block. Iverson's scheme works
only if all existing comments fall at the end of the line.
In any event, the comment is wrong. `*' is a metacharacter for the
grep program, so the pattern matches lines starting with one or more
`/'s. "^/\*\*/" is more correct, when such comments are not indented.
(To forestall a misunderstanding: a C comment cannot be nested within
another comment, as in
/* comment comment /* nested comment */ more comment */
Never. If your compiler allows it, it is not compiling C at that
time. It is compiling a language that misleadingly resembles C. It
will fail to compile the following program, which has been legal C
since Cambrian times.
#include <stdio.h>
main() {/* int x; /* a count */ printf("Hello world!\n"); exit(0);}
)
--
Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA
Work phone: +1 313 973 1300 Home phone: +1 313 677 4386
Internet: mcdaniel@adi.com UUCP: {uunet,sharkey}!amara!mcdanielrmartin@clear.com (Bob Martin) (12/29/90)
In article <1990Dec27.215842.23685@ivy.uucp> iverson@ivy.uucp (Tim Iverson) writes: >Actually, you don't have to put the closing '*/' on the *end* of the line: > >/* e.g. these lines are commented out /* even if they have comments */ >/* You can also grep for "^/**/" to find where they all are. >/**/ > I personally vote for inclusion of the // comment in the ANSI standard. Does anybody know what the standard says about nested comments? i.e. /* /* is this valid /* or will it generate errors /**/ The sun C++ compiler chokes on comments like this, as do a few other C compilers around. What is the official stance. -- +-Robert C. Martin-----+:RRR:::CCC:M:::::M:| Nobody is responsible for | | rmartin@clear.com |:R::R:C::::M:M:M:M:| my words but me. I want | | uunet!clrcom!rmartin |:RRR::C::::M::M::M:| all the credit, and all | +----------------------+:R::R::CCC:M:::::M:| the blame. So there. |
iverson@bang.uucp (Superuser) (12/29/90)
In article <MCDANIEL.90Dec28110944@dolphin.adi.com> mcdaniel@adi.com (Tim McDaniel) writes: >iverson@ivy.uucp (Tim Iverson) screwed up, I'm afraid. Arrrggggghhhh! Yes, I screwed up - though I can honestly say that in 5 years of programming in C, I've never had a problem with it. Probably because comments /* in the middle */ of a line are rare (nonexistent in my own code). > gcc -Wall -ansi -pedantic 72.c I should have known this group would be full of nit-picking pedants :-) > 72.c:2: warning: `/*' within comment > 72.c:3: warning: `/*' within comment > 72.c:3: unterminated string or character constant I also never intended the actual lines to be fed into a real compiler. They were intended to illustrate a point and communicate at the same time - after all, walking and chewing gum at the same time works. >The `*/' on line 3 ends the comment block. Iverson's scheme works >only if all existing comments fall at the end of the line. After reading this and realizing the flaw in this technique, I kept on trying to justify using to myself, but the only thing about it that appeals to me now is that it is esthetically pleasing to look at - it really jumps out of the page on a listing. Perhaps now I'll change to using #ifdef full-time instead of just for permanent out-takes. >In any event, the comment is wrong. `*' is a metacharacter for the >grep program, so the pattern matches lines starting with one or more >`/'s. "^/\*\*/" is more correct, when such comments are not indented. Well, obviously you understood what I meant, but your escapes are actually just as correct as mine (i.e. dead wrong - Ha! I just had to find some nit to pick in your posting :-). Try grep "^/\\*\\*/"; the shell eats your unescaped escape. >Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA >Internet: mcdaniel@adi.com UUCP: {uunet,sharkey}!amara!mcdaniel - Tim Iverson uunet!xstor!iverson
mcdaniel@adi.com (Tim McDaniel) (01/01/91)
With certain options, gcc and FlexeLint complain about `/*' within
comments. In my coding style, these warnings are a sign of something
wrong. Your milage may vary. Prohibited where "void" is prohibited.
grep "^/\*\*/" works under csh and sh (SUN OS 4.1). grep "^/\\*\\*/"
works under sh. I don't know what the Adventure shell would do.
Further discussion by e-mail; it's not a C point, so I shouldn't have
commented on it in the first place.
--
Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA
Work phone: +1 313 973 1300 Home phone: +1 313 677 4386
Internet: mcdaniel@adi.com UUCP: {uunet,sharkey}!amara!mcdanielron@scocan.sco.COM (Ron Irvine) (01/05/91)
A need for // (real) comments:
#include <stdio.h>
void main() {
int *p;
int a;
int f = 10;
int n = 5;
p = &f;
a = 100/*p /* calculate first factor */
+ 25/n; /* and second factor */
printf("The answer is %d, %s\n", a, (a==15)?"OK":"BAD");
}
The actual program that contained this problem was very complex.
It took two of us a day to figure out what had happened.
Flame On:
It is incredibly STUPID to have the start of comment token the same
as a LEGAL combination of other language tokens.
I have run this program on 4 different C compilers and none of them
even warned of a potential problem (nested comments).
Comments are part of the syntax of the language and should never
have been left to the EVIL pre-processor to "handle".
Flame Off:
The // comment style should have been adopted by the ANSI committee
if for no other reason that to reduce the likelihood of a programmer
falling into this horrendous trap. If // style comments had been
used in the above program the compile would have failed.
Ron Irvine, ron@sco.comsef@kithrup.COM (Sean Eric Fagan) (01/06/91)
In article <1991Jan04.164355.15674@sco.COM> ron@scocan.sco.COM (Ron Irvine) writes: >The actual program that contained this problem was very complex. >It took two of us a day to figure out what had happened. I would have run it through the preprocessor to figure out what was going on. Shouldn't have taken too long. >The // comment style should have been adopted by the ANSI committee >if for no other reason that to reduce the likelihood of a programmer >falling into this horrendous trap. If // style comments had been >used in the above program the compile would have failed. Fine. Please show me an existing C compiler that handles this. Please tell me how you are going to handle // we want to see if the character is a \ if (c == '\\') Is the if statement part of the comment, or not? In C comments, no characters are special. /lib/cpp says that /* This is a comment? /\ * results in an unterminated comment, while msc and gcc both accept it. X3J11's job was to standardize *C*, not change it. They added trigraphs, and nobody is happy with them. They added prototypes, and people like them. They added noalias, and god himself (dmr 8-)) bore his wrath down upon them. I know of only one C compiler that accepts //-style comments: Microsoft C, versions 5.0 and later. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
barmar@think.com (Barry Margolin) (01/06/91)
In article <1991Jan04.164355.15674@sco.COM> ron@scocan.sco.COM (Ron Irvine) writes: >The // comment style should have been adopted by the ANSI committee >if for no other reason that to reduce the likelihood of a programmer >falling into this horrendous trap. If // style comments had been >used in the above program the compile would have failed. And if they got rid of malloc and free then programmers wouldn't forget to free storage.... Seriously, though, the purpose of a language standard is to support portability of programs, not to hold the programmers' hands. Also, it's quite likely that including // comments in the standard wouldn't help so much, because many programmers wouldn't use them. For quite some time programmers will continue to be concerned with porting their programs to non-ANSI compilers (the C compilers that are bundled with many popular OSes (e.g. SunOS) aren't ANSI-compliant), so they'll use the more compatible commenting style. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
dave@cs.arizona.edu (Dave P. Schaumann) (01/06/91)
In article <1991Jan04.164355.15674@sco.COM> ron@scocan.sco.COM (Ron Irvine) writes:
!A need for // (real) comments:
!
!
!#include <stdio.h!
!void main() {
! int *p;
! int a;
! int f = 10;
! int n = 5;
!
! p = &f;
!
! a = 100/*p /* calculate first factor */
! + 25/n; /* and second factor */
!
! printf("The answer is %d, %s\n", a, (a==15)?"OK":"BAD");
!}
!
!
!The actual program that contained this problem was very complex.
!It took two of us a day to figure out what had happened.
!
! [ flame about compilers missing /* within comment deleted ]
The failure, IMHO, is in the compiler for not testing for the sequence /*
within the comment. I think this should be a required feature of every ansi
c compiler. Note that if you are using gcc, -Wall will notify you of this.
!The // comment style should have been adopted by the ANSI committee
!if for no other reason that to reduce the likelihood of a programmer
!falling into this horrendous trap. If // style comments had been
!used in the above program the compile would have failed.
Only if /* */ style comments were not used. Personally, I have no great love
for /* */ comments, but I see no compelling reason to have //, and have heard
no argument for // that doesn't boil down to 'I like it that way better'.
!Ron Irvine, ron@sco.com
Dave Schaumann | You are in a twisty maze of little
dave@cs.arizona.edu | C statements, all different.joe@proto.COM (Joe Huffman) (01/06/91)
In article <1991Jan04.164355.15674@sco.COM>, ron@scocan.sco.COM (Ron Irvine) writes: > A need for // (real) comments: > > > #include <stdio.h> > void main() { > int *p; > int a; > int f = 10; > int n = 5; > > p = &f; > > a = 100/*p /* calculate first factor */ > + 25/n; /* and second factor */ > > printf("The answer is %d, %s\n", a, (a==15)?"OK":"BAD"); > } > > I have run this program on 4 different C compilers and none of them > even warned of a potential problem (nested comments). This is the response the Zortech compiler for SCO UNIX gave for the sample code: ztc1 -DM_UNIX -DM_XOUT -f -3 -o/tmp/ztc_3HL.tmp ron a = 100/*p /* calculate first factor */ ^ ron.c(27) : Warning: can't nest comments Time to switch compilers? :-) --- Zortech mailing list: send email to 'ztc-list-request@uunet.uu.net' with: Add: your-user-name@your-machine-name In the body of the message. --- Send Zortech bug reports to 'zortech-bugs@proto.com' Send requests for educational discounts to 'zortech-ed@proto.com' --- Zortech is my major source of income. Statements about them or their competitors cannot be totally without bias. -- joe@proto.com
henry@zoo.toronto.edu (Henry Spencer) (01/06/91)
In article <1991Jan04.164355.15674@sco.COM> ron@scocan.sco.COM (Ron Irvine) writes: > a = 100/*p /* calculate first factor */ >I have run this program on 4 different C compilers and none of them >even warned of a potential problem (nested comments). Four different compilers, or four different ports of the same compiler? (Many Unix C compilers are really the same one, good [?] old PCC.) An alert compiler *will* warn about this. >Comments are part of the syntax of the language and should never >have been left to the EVIL pre-processor to "handle". They aren't, and weren't. What makes you think the preprocessor is involved? In old compilers, typically *both* the preprocessor and the compiler do comment elimination. C's comment style was fixed before the preprocessor even existed. >The // comment style should have been adopted by the ANSI committee >if for no other reason that to reduce the likelihood of a programmer >falling into this horrendous trap... Careless programmers would still fall into it, because vast numbers of old compilers are still in the field, and code intended to be portable must be acceptable to them. -- "The average pointer, statistically, |Henry Spencer at U of Toronto Zoology points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu utzoo!henry
darcy@druid.uucp (D'Arcy J.M. Cain) (01/06/91)
In article <1991Jan04.164355.15674@sco.COM> Ron Irvine writes: > a = 100/*p /* calculate first factor */ > + 25/n; /* and second factor */ > >It is incredibly STUPID to have the start of comment token the same >as a LEGAL combination of other language tokens. >I have run this program on 4 different C compilers and none of them >even warned of a potential problem (nested comments). Then you didn't try Gnu C with the -Wall option: tst.c:10 warning: `/*' within comment Turbo C generated a warning as well but it was because p was assigned a value and then never used. That's a warning I wish gcc issued. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | There's no government West Hill, Ontario, Canada | like no government! +1 416 281 6094 |
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/07/91)
In article <613@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: > I see no compelling reason to have //, and have heard > no argument for // that doesn't boil down to 'I like it that way better'. 1. // cannot be a substring of non-quoted C code that would be legal if the language didn't have comments. /* can. (This is just an obfuscated way of saying ``/* often produces errors because x/*p is legal.'') 2. // is shorter and easier to type than /* */. 3. // is more visually striking than /* ... */. 4. It is always obvious, to both human eye and mechanical parser, where a // comment ends (viz., the end of the line). It is not so trivial to locate the next */. 5. Placing // at the beginning of several lines is guaranteed to comment out the entire section. There is no easily applied rule for /*...*/. 6. An end-of-line comment mechanism can double as the line continuation mechanism, as in TeX. This is a beautifully simple way to kill two birds with one stone; it cuts the relevant sections of the standard in half. 7. There's always lots of fuss over matched comments as in C, while there's never a fuss over per-line comments as in the shells or TeX. There. Now you've heard several arguments for // that don't boil down to ``I like it that way better.'' You may not consider them compelling but you can't say they don't exist. ---Dan
diamond@jit345.swstokyo.dec.com (Norman Diamond) (01/07/91)
In article <1990Dec29.040256.21708@clear.com> rmartin@clear.com (Bob Martin) writes: >Does anybody know what the standard says about nested comments? >i.e. /* > /* is this valid > /* or will it generate errors > /**/ >The sun C++ compiler chokes on comments like this, as do a few other C >compilers around. What is the official stance. So the sun C++ compiler is does not conform to the ANSI C standard. No C++ compiler can, though not for this reason. The other compilers mentioned are not ANSI C compilers, though they seem to be asserted as compilers for other dialects of C. Extraneous warnings are allowed (and are obviously desirable in this case, though should be optionable), but choking is not allowed. -- -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
karl@ima.isc.com (Karl Heuer) (01/07/91)
In article <1050:Jan701:40:4791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <613@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: >> I see no compelling reason to have //, and have heard >> no argument for // that doesn't boil down to 'I like it that way better'. > >[Several arguments deleted] My favorite is the observation that virtually all% one-line comments end with a newline following the "*/", and virtually all% multi-line comments have cosmetic punctuation (usually " * ") at the beginning of each line, anyway. So it seems clear that the programmers are, at some level, *thinking* in terms of comment-to-EOL, and it probably would have been better for the comment syntax to have reflected that in the first place. I don't claim this is a compelling reason, and I won't even dispute that it's just a variant of "I like it that way better". The fact that I first came up with this idea, including the "//" symbol, years before I knew that BCPL and C++ used "//" comments, will be of interest to those individuals who take an interest in that sort of thing. Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint ________ % There are a few exceptions, but I don't find *them* compelling, so there :-)
dave@cs.arizona.edu (Dave P. Schaumann) (01/07/91)
In article <1050:Jan701:40:4791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |In article <613@caslon.cs.arizona.edu| dave@cs.arizona.edu (Dave P. Schaumann) writes: || I see no compelling reason to have //, and have heard || no argument for // that doesn't boil down to 'I like it that way better'. |1. [ x/*p can be evaluated as a reasonable expression ] This is a reasonable argument against why /* is a poor choice as a comment starter. However, the time to point this out was 20 years ago, when Dennis Ritchie was designing C. Adding // would help you avoid this error, but so would using white space around binary operators. (I always do.) |2. // is shorter and easier to type than /* */. |3. // is more visually striking than /* ... */. These are matters of personal taste. |4. It is always obvious, to both human eye and mechanical parser, where |a // comment ends (viz., the end of the line). It is not so trivial to |locate the next */. My editor has a 'search for text' function. Doesn't yours? |5. Placing // at the beginning of several lines is guaranteed to comment |out the entire section. There is no easily applied rule for /*...*/. Comments are not for hiding code from the compiler. #if/#endif and all their cousins are for that. Complaining that /* */ doesn't work well to 'comment out code' is like complaining a socket wrench makes a poor hammer. |6. An end-of-line comment mechanism can double as the line continuation |mechanism, as in TeX. This is a beautifully simple way to kill two birds |with one stone; it cuts the relevant sections of the standard in half. Unfortunately, I don't know what you are referring to here, so I can't comment. |7. There's always lots of fuss over matched comments as in C, while |there's never a fuss over per-line comments as in the shells or TeX. I agree that it could be easy to misplace a */ when entering code. However, as another post points out, // comments can have there own pitfalls when the line ends with a '\'. |There. Now you've heard several arguments for // that don't boil down to |``I like it that way better.'' You may not consider them compelling but |you can't say they don't exist. | |---Dan Dave Schaumann | My folks went to uunet.uu.net, but all dave@cs.arizona.edu | they got me was this lousy .sig...
sef@kithrup.COM (Sean Eric Fagan) (01/07/91)
In article <1991Jan7.023042.23190@jituha.enet.dec.com> diamond%tkov50.enet.dec.com (Norman Diamond) writes: >The other compilers mentioned are not ANSI C compilers, Uhm... gcc is an ansi compiler. It takes some special flags to get that, but that is permitted by ANSI. (POSIX, on the other hand, is a different matter... from what I can understand there, cc89 is supposed to get you a compiler that, by default, conforms to both standards.) >Extraneous warnings >are allowed (and are obviously desirable in this case, though should be >optionable), but choking is not allowed. gcc didn't choke. It warned about it, if you request it, which is a Nice Thing. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
funkstr@ucscb.UCSC.EDU (Larry Hastings) (01/07/91)
+-In article <1991Jan05.194321.12428@kithrup.COM>, | sef@kithrup.COM (Sean Eric Fagan) wrote: | | I know of only one C compiler that accepts //-style comments: Microsoft C, | versions 5.0 and later. +---------- Well, that's certainly not all of them; Turbo C++ (and perhaps Turbo C 2.0) for DOS accepts // comments, as do all the MetaWare compilers since version 1.5 (which is about two years). As for /* */ style comments, I'd just use /*/ for both ends if I could get away with it. This makes it possible to have a single keymacro that emits both the begin and end comment markers. Comments would now look like: printf("\n"); /*/ I'm commenting this line for no reason /*/ This works quite well with all the compilers I have handy. The only reason I don't do this is because I'm afraid my coworkers would form a lynch mob. -- larry hastings, the galactic funkster, funkstr@ucscb.ucsc.edu I don't speak for Knowledge Dynamics or UC Santa Cruz, nor do they speak for me "People, it's Fonzie with Teret's syndrome!"--Dennis Miller on Andrew Dice Clay p.s. I'm kidding about the /*/ comment markers, in case you can't tell -- but I may work them in to an obfuscated C code contest entry
bhoughto@hopi.intel.com (Blair P. Houghton) (01/08/91)
In article <616@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: >In article <1050:Jan701:40:4791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >|In article <613@caslon.cs.arizona.edu| dave@cs.arizona.edu (Dave P. Schaumann) writes: >|| I see no compelling reason to have //, and have heard >|| no argument for // that doesn't boil down to 'I like it that way better'. The political scientists can prove to you why it ever will be thus. >|4. It is always obvious, to both human eye and mechanical parser, where >|a // comment ends (viz., the end of the line). It is not so trivial to >|locate the next */. > >My editor has a 'search for text' function. Doesn't yours? Many editors use softlines; i.e., there is no end-of-line in the file, though your screen and eyes see one. With a pre- and post-delimiting comment format these editors are not obsolesced (lame reason). Recall that the ends of lines in the translation units are a user convenience only, and the compiler is allowed to be able to treat the entire program as one long line (cf. the 509-character minimum-maximum limit), if it so wishes. Pathological storage schemes may find this necessary, obviating any construct requiring the newline glyph in the translation unit. I.e., it is to lose-lose. >|6. An end-of-line comment mechanism can double as the line continuation >|mechanism, as in TeX. This is a beautifully simple way to kill two birds >|with one stone; it cuts the relevant sections of the standard in half. > >Unfortunately, I don't know what you are referring to here, so I can't comment. Likewise. TeX ignores newlines, unless you tell it not to, as for example by placing a comment there, which it then ignores. >|7. There's always lots of fuss over matched comments as in C, while >|there's never a fuss over per-line comments as in the shells or TeX. > >I agree that it could be easy to misplace a */ when entering code. However, as >another post points out, // comments can have there own pitfalls when the line >ends with a '\'. Shells and TeX[*] have very important reasons for making newlines significant; although TeX ignores them and sh(1) can be made to run without them, in which case it would be REALLY NICE to have a double-ended, comment-delimiting scheme for them both. >|There. Now you've heard several arguments for // that don't boil down to >|``I like it that way better.'' You may not consider them compelling but >|you can't say they don't exist. Like I said: the former case the political scientists could refute. The latter, you win. --Blair "//let's hope you never get stuck\n\ // trying to look too closely\n\ // at something like this...\n" [*] Not to be confused with Kraft Shells and Cheese, which is much more tasty than anything under Unix... :-)
henry@zoo.toronto.edu (Henry Spencer) (01/08/91)
In article <1990Dec29.040256.21708@clear.com> rmartin@clear.com (Bob Martin) writes: >I personally vote for inclusion of the // comment in the ANSI standard. Far too late. The ANSI C standard has already been finalized, ratified, and published. Incidentally, you don't get to vote on such things unless you're a member of the relevant committee (which is open to anyone, although there are fees involved). >Does anybody know what the standard says about nested comments? The standard, like all definitions of C since the beginning, says quite explicitly that comments do not nest. -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
gwyn@smoke.brl.mil (Doug Gwyn) (01/08/91)
In article <276814F4.141@maccs.dcss.mcmaster.ca> kevinb@maccs.dcss.mcmaster.ca (Kevin Boyes) writes: >Does any one know why the ANSI committee excluded the C++ comment style >( // to end of line ) from the standard. Sure, I know why. Surely by now you should be able to guess the reason.
diamond@jit345.swstokyo.dec.com (Norman Diamond) (01/08/91)
In article <1050:Jan701:40:4791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >4. It is always obvious, to both human eye and mechanical parser, where >a // comment ends (viz., the end of the line). It is not so trivial to >locate the next */. If it's so obvious, then why was there so much confusion for a while, over in the C++ newsgroups? It seems to have been resolved, that if a comment constains a backslash followed by a newline, the backslash and newline get eaten early the way ANSI C says, and extend the comment. But for a while, they didn't find it so obvious. In article <1991Jan05.194321.12428@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >Is the if statement part of the comment, or not? In C comments, no >characters are special. Well, after the trigraphs have been kluged, backslash-newlines eaten, and terminating asterisk-slashes honored, there are no special characters remaining in the comments. >/lib/cpp says that > /* > This is a comment? > /\ > * >results in an unterminated comment, while msc and gcc both accept it. I'd agree that /* This is a comment? /* results in an unterminated comment. What does /lib/cpp say when you terminate the comment? How old a /lib/cpp are you using? -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/08/91)
In article <1991Jan05.194321.12428@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > Fine. Please show me an existing C compiler that handles this. Please tell > me how you are going to handle > // we want to see if the character is a \ > if (c == '\\') But that's the beauty of end-of-line comments: You *automatically* delete everything, including the newline itself. // is both the comment mechanism and the continuation mechanism. All characters past //, through the newline, are ignored. Apparently Microsoft C doesn't do this right. Oh, well. > X3J11's job was to standardize *C*, not change it. Agreed. I don't think they should have added //, or trigraphs, or prototypes, or noalias. But // is still better than /* */. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/08/91)
In article <1640@inews.intel.com> bhoughto@hopi.intel.com (Blair P. Houghton) writes: > Likewise. TeX ignores newlines, unless you tell it not to, > as for example by placing a comment there, which it then ignores. No, TeX doesn't ignore newlines. Sorry I didn't explain this well enough the first time. Here's a complete parser for TeX's end-of-line % comment mechanism: When you see %, read and throw away characters until newline. Throw away the newline as well. Continue. For a programming language it's probably better to replace the newline with a space than to concatenate the lines around it, for the same reason that /*foo*/ becomes a space in (non-cpp) C. But the point is that this mechanism handles both comments and continuations in one fell swoop. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/08/91)
In article <616@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: > In article <1050:Jan701:40:4791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > |1. [ x/*p can be evaluated as a reasonable expression ] > This is a reasonable argument against why /* is a poor choice as a comment > starter. However, the time to point this out was 20 years ago, when Dennis > Ritchie was designing C. I'm not saying that we should rush to change anything. It's just a point to remember for the future: // comments would help avoid a common error. Similarly, I don't think we should rush to change strcmp() to strdiff(), but we should remember that the latter would help avoid a common error. > |2. // is shorter and easier to type than /* */. > |3. // is more visually striking than /* ... */. > These are matters of personal taste. No. #2 is an objective fact and #3 is a widely accepted principle of visual design: parallel lines are striking. Read Tufte's books. > |4. It is always obvious, to both human eye and mechanical parser, where > |a // comment ends (viz., the end of the line). It is not so trivial to > |locate the next */. > My editor has a 'search for text' function. Doesn't yours? My eyes don't have a ``search for text'' function, and it takes just a bit longer for the computer to recognize a two-character sequence than to recognize a one-character sequence. > |5. Placing // at the beginning of several lines is guaranteed to comment > |out the entire section. There is no easily applied rule for /*...*/. > Comments are not for hiding code from the compiler. But the fact is that people want to use comments to hide code (and text). #if/#endif is not safe for hiding code and simply doesn't work right for hiding text. > However, as > another post points out, // comments can have there own pitfalls when the line > ends with a '\'. No, not when they're done correctly. When you have end-of-line comments there's no need for continuation characters. *All* characters are ignored between // and newline inclusive. ---Dan
guido@cwi.nl (Guido van Rossum) (01/08/91)
In comp.std.c you write: >[...] When you have end-of-line comments >there's no need for continuation characters. *All* characters are >ignored between // and newline inclusive. Your assumption (which you mention in several of your postings) is that newline is not significant to the C compiler. But it is to the preprocessor because #include etc. must be at the start of a line. The following example does not #include <stdio.h>: /* This line is continued... */ \ #include <stdio.h> -- Guido van Rossum, CWI, Amsterdam <guido@cwi.nl> "Pablo Picasso was never called an asshole"
ron@scocan.sco.COM (Ron Irvine) (01/09/91)
> In article <1991Jan04.164355.15674@sco.COM> ron@scocan.sco.COM (Ron Irvine) writes: > > a = 100/*p /* calculate first factor */ > >I have run this program on 4 different C compilers and none of them > >even warned of a potential problem (nested comments). > > Four different compilers, or four different ports of the same compiler? > (Many Unix C compilers are really the same one, good [?] old PCC.) An > alert compiler *will* warn about this. > > Henry Spencer at U of Toronto Zoology The four compilers: gcc 1.38 on a 386, SCO/Microsoft C 386, AT&T C 386, and Turbo C++/C on DOS. Four very different compilers. |----------------- | ANSI C Section 3.1.9 Comments: | | Except within a character constant, a string literal, or a | comment, the characters /* introduce a comment. The contents of | a comment are examined only to identify multibyte characters | and to find the characters */ that terminate it. 26 | | 26. Thus, comments do not nest. |---------------- Thus, a compiler that gives a warning of nested comments upon finding the characters /* within a comment must have "examined" the contents of the comment beyond that specified by the standard and is in violation of the standard. So, the four compilers I used were in fact processing the code correctly and were correct in not producing a warning. Ron Irvine, ron@sco.com
fouts@bozeman.ingr.com (Martin Fouts) (01/09/91)
>>>>> On 8 Jan 91 04:38:15 GMT, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) said: Dan> In article <616@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: > In article <1050:Jan701:40:4791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: [ Discussion of point deleted] > |2. // is shorter and easier to type than /* */. > |3. // is more visually striking than /* ... */. > These are matters of personal taste. Dan> No. #2 is an objective fact and #3 is a widely accepted principle of Dan> visual design: parallel lines are striking. Read Tufte's books. Sorry, #2 is not an objective fact. In my editor of choice, I type esc-; to "build" a comment. It decides if I want // or /* */ from various context clues and leaves me in the right place to enter the comment. I type newline when I'm through and the editor moves me on. Same number of keystrokes in either case. > |4. It is always obvious, to both human eye and mechanical parser, where > |a // comment ends (viz., the end of the line). It is not so trivial to > |locate the next */. > My editor has a 'search for text' function. Doesn't yours? Dan> My eyes don't have a ``search for text'' function, and it takes just a Dan> bit longer for the computer to recognize a two-character sequence than Dan> to recognize a one-character sequence. The latter is true, but irrelavent, as the "newline" character is often a two character sequence internally in non Unix operating systems. > |5. Placing // at the beginning of several lines is guaranteed to comment > |out the entire section. There is no easily applied rule for /*...*/. > Comments are not for hiding code from the compiler. Dan> But the fact is that people want to use comments to hide code (and Dan> text). #if/#endif is not safe for hiding code and simply doesn't work Dan> right for hiding text. > However, as > another post points out, // comments can have there own pitfalls when the line > ends with a '\'. Dan> No, not when they're done correctly. When you have end-of-line comments Dan> there's no need for continuation characters. *All* characters are Dan> ignored between // and newline inclusive. Ah, but the other form isn't a problem "when done correctly" either. The original a/*p problem goes away if you always follow the rule of inserting whitespace between tokens. Dan> ---Dan Anyway, at this point, it would be nearly impossible to remove '/*..*/' from the language, and the introduction of // adds additional opportunities for ambiguity. Consider the statement: i = a//*p*/b; This is a valid C statement now, but might not be if both kinds of comments were supported in the language. (Sigh.) -- Martin Fouts Software Craftsman EMAIL: fouts@apd.ingr.com PHONE: (415) 852-2310 FAX: (415) 856-9224 MAIL: 2400 Geng Road, Palo Alto, CA, 94303 Moving to Montana; Goin' to be a Dental Floss Tycoon. - Frank Zappa
frank@grep.co.uk (Frank Wales) (01/09/91)
In article <616@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: >In article <1050:Jan701:40:4791@kramden.acf.nyu.edu> > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >|4. It is always obvious, to both human eye and mechanical parser, where >|a // comment ends (viz., the end of the line). It is not so trivial to >|locate the next */. > >My editor has a 'search for text' function. Doesn't yours? My editor doesn't have a 'search for text in printouts' function. Does yours? -- Frank Wales, Grep Limited, [frank@grep.co.uk<->uunet!grep!frank] Kirkfields Business Centre, Kirk Lane, LEEDS, UK, LS19 7LX. (+44) 532 500303
datangua@watmath.waterloo.edu (David Tanguay) (01/09/91)
In article <17968:Jan804:38:1591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >No. #2 is an objective fact and #3 is a widely accepted principle of >visual design: parallel lines are striking. Read Tufte's books. Then Tufte is wrong, at least in this instance :-) One of the problems I have found with C++ code is that I don't see the comments (caveat: I've not looked at a lot of C++ code). The // looks like a letter to me (it's almost an italic N). >No, not when they're done correctly. When you have end-of-line comments >there's no need for continuation characters. *All* characters are >ignored between // and newline inclusive. What about: #define BLAH stuff // comment about BLAH some code here If the newline is stripped, then "some code here" becomes part of the macro, which seems nasty. -- David Tanguay Software Development Group, University of Waterloo
condict@mirabeau.osf.fr (Michael Condict) (01/09/91)
In <17968:Jan804:38:1591@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >> However, as >> another post points out, // comments can have there own pitfalls when the line >> ends with a '\'. > > No, not when they're done correctly. When you have end-of-line comments > there's no need for continuation characters. *All* characters are > ignored between // and newline inclusive. This is an unwarranted generalization (that end-of-line comments eliminate the need for a continuation character), which doesn't really work in C. For example, do you really want to disallow the following? #define min_size 10 // Minimum size allowed for foo array #define max_size 20 // Maximum size allowed for foo array Your proposal would require putting a blank line between the two #defines. Also, you said that the comment would turn into a space, rather than simply being deleted, which I agree is necessary in order to separate the token preceding it from the first token on the next line. But then how do you get the effect of: s = "123456789abcdefghijklmnopqrstuvwxyz\ ABCDEFGHIJKLMNOPQRSTUVWXYZ"; using your comment notation? Even assuming the comment delimiter is to be recognized inside of quotes, a bad idea in itself, you would produce an unwanted blank character in the string. Michael Condict
rtm@christmas.UUCP (Richard Minner) (01/09/91)
In article <17444:Jan804:03:3291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >But that's the beauty of end-of-line comments: You *automatically* >delete everything, including the newline itself. // is both the comment >mechanism and the continuation mechanism. All characters past //, >through the newline, are ignored. > >Apparently Microsoft C doesn't do this right. Oh, well. No, // doesn't necessarily eat the newline in C++: ARM 2.2 Comments: ... The characters // start a comment, which terminates at the end of the line on which they occur. We'll let the ANSI folks tell us if "line" means "physical line" or "logical line", but in either case it doesn't seem to imply the logical joining of the current line with the next. If it did, then #define THIS // blah blah #define THAT // blah blah would break. And so would ... #endif //... <code> Remember, newlines are usually just white space, but not always to the preprocessor. I personally don't hate /* */ so much, but just to keep this wonderous thread going (anyone keeping count?) there's another really super big advantage of // that I haven't seen mentioned. If you want to write a header for a function or file and include an example of usage that actually looks like regular code with normal comments, you can't do it with /* */ without resorting to some pretty ugly guck with #if/#endif. With // it's trivial. -- Richard Minner || {uunet,sun,well}!island!rtm (916) 736-1323 || || Island Graphics Corporation Sacramento, CA ||
chris@mimsy.umd.edu (Chris Torek) (01/09/91)
>In article <17968:Jan804:38:1591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >>... is a widely accepted principle of >>visual design: parallel lines are striking. Read Tufte's books. In article <1991Jan9.003543.3087@watmath.waterloo.edu> datangua@watmath.waterloo.edu (David Tanguay) writes: >Then Tufte is wrong, at least in this instance :-) One of the problems I >have found with C++ code is that I don't see the comments (caveat: I've not >looked at a lot of C++ code). The // looks like a letter to me (it's almost >an italic N). Actually, no smiley face is needed. Although the brain has special `hardware' for recognizing lines (and, in particular, horizontal and vertical lines; diagonals seem to take longer---one can speculate about animals hidden in tall grasses here), in the sequence some stuff with a // comment the lines are not really large enough to be picked out. Extending them to two screen positions will usually suffice: some stuff with a // strange and somewhat special // comment provided that these line up properly on your screen (a few seconds of arc can make a big difference here). The human visual system is kind of weird. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
andrew@resam.dk (Leif Andrew Rump) (01/09/91)
In <10690@darkstar.ucsc.edu> funkstr@ucscb.UCSC.EDU (Larry Hastings) writes: >As for /* */ style comments, I'd just use /*/ for both ends if I could >get away with it. This makes it possible to have a single keymacro that emits >both the begin and end comment markers. Comments would now look like: > printf("\n"); /*/ I'm commenting this line for no reason /*/ >This works quite well with all the compilers I have handy. The only reason I >don't do this is because I'm afraid my coworkers would form a lynch mob. Well our Sun C compiler which sure _isn't_ ANSI C compatible allow quite a few things: #include <stdio.h> main() { int my/* Comments is _not_ considered as a white space */var; /* /* // It doesn't detect nested comments fprintf(stderr, "Hello"); /*/ fprintf(stderr, " World"); /*/ fprintf(stderr, "\n"); */ myvar = 1; } >p.s. I'm kidding about the /*/ comment markers, in case you can't tell -- but > I may work them in to an obfuscated C code contest entry Does you C compiler not allow it or do You consider it bad programming? :-) The above code compiled on a Sun producing " World" as output. And the comment toggling is a neat feature!!! :-) :-/ :-( 8-( *-( [Sigh] Leif Andrew Leif Andrew Rump, AmbraSoft A/S, Stroedamvej 50, DK-2100 Copenhagen OE, Denmark UUCP: andrew@ambra.dk, phone: +45 39 27 11 77 / Currently at Scandinavian Airline Systems =======/ UUCP: andrew@resam.dk, phone: +45 32 32 51 54 \ SAS, RESAM Project Office, CPHML-V, P.O.BOX 150, DK-2770 Kastrup, Denmark > > Read oe as: o <backspace> / (slash) and OE as O <backspace> / (slash) < <
dave@cs.arizona.edu (Dave P. Schaumann) (01/09/91)
In article <1991Jan08.192415.3361@grep.co.uk> frank@grep.co.uk (Frank Wales) writes: |In article <616@caslon.cs.arizona.edu| dave@cs.arizona.edu (Dave P. Schaumann) | writes: ||In article <1050:Jan701:40:4791@kramden.acf.nyu.edu| || brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |||4. It is always obvious, to both human eye and mechanical parser, where |||a // comment ends (viz., the end of the line). It is not so trivial to |||locate the next */. || ||My editor has a 'search for text' function. Doesn't yours? | |My editor doesn't have a 'search for text in printouts' function. Does yours? Actually, I considered this point when I was making the original post. The reason I decided it wasn't important is that I can't imagine doing any serious work on a program when only hardcopy is available. (*Surely* there is an on-line copy somewhere!) |Frank Wales, Grep Limited, [frank@grep.co.uk<-|uunet!grep!frank] |Kirkfields Business Centre, Kirk Lane, LEEDS, UK, LS19 7LX. (+44) 532 500303 Dave Schaumann | My folks went to uunet.uu.net, but all dave@cs.arizona.edu | they got me was this lousy .sig...
tj@Alliant.COM (Tom Jaskiewicz) (01/10/91)
My first impression of // comments was that they are a harmless addition
to the language. After reading some of the discussion in this newgroup
I now believe that they are not harmless. // comments would add no new
capabilities to the language (comments are already possible), but would
add an interesting set of interactions with other language features.
If you do add // comments to c, what does the following code do?
/* printf("One\n"); /* 1 */
printf("Two\n"); /* 2 */
/* printf("Three\n");
// printf("Four\n"); /* 4 */
printf("Five\n"); /* 5 */
// printf("Six\n"); /* 6
printf("Seven\n"); /* 7 */
/* printf("Eight\n");
// */ printf("Nine\n");
printf("Ten\n"); /* 10 */
This makes // look like a dangerous idea.
--
##########################################################################
# The doctrine of nonresistance against arbitrary power, and oppression is
# absurd, slavish, and destructive of the good and happiness of mankind.
# -- Article 10, Part First, Constitution of New Hampshireflaps@dgp.toronto.edu (Alan J Rosenthal) (01/10/91)
Sigh, it is not the case that `//' commenting would always require fewer characters. Consider the following (blecherous) style: /* Once upon a time, in a land far away, there was a C compiler. This compiler compiled many programs and had many happy users. */ Compare that to this: // Once upon a time, in a land far away, // there was a C compiler. This compiler // compiled many programs and had many // happy users. I count 6 extra characters in the first case, including newlines, and 12 in the second. ajr
andrew@resam.dk (Leif Andrew Rump) (01/11/91)
In <10852@darkstar.ucsc.edu> funkstr@ucscb.UCSC.EDU (Larry Hastings) writes: >+-In article <4423@alliant.Alliant.COM>, >| tj@Alliant.COM (Tom Jaskiewicz) wrote: >| >| My first impression of // comments was that they are a harmless addition >| to the language. After reading some of the discussion in this newgroup >| I now believe that they are not harmless. >| >| If you do add // comments to c, what does the following code do? >| >| /* printf("One\n"); /* 1 */ >| printf("Two\n"); /* 2 */ >| /* printf("Three\n"); >| // printf("Four\n"); /* 4 */ >| printf("Five\n"); /* 5 */ >| // printf("Six\n"); /* 6 >| printf("Seven\n"); /* 7 */ >| /* printf("Eight\n"); >| // */ printf("Nine\n"); >| printf("Ten\n"); /* 10 */ >+---------- >Well, under Turbo C (which supports // comments in "Turbo C" and "Turbo C++" >modes"), this prints >Two >Five >Seven >Nine >Ten Just a single question: Does TC warn you about comment (/*) inside a comment (//)? If not then _I_ will never mix // and /**/ and maybe even abandon // completely!!! Leif Andrew Leif Andrew Rump, AmbraSoft A/S, Stroedamvej 50, DK-2100 Copenhagen OE, Denmark UUCP: andrew@ambra.dk, phone: +45 39 27 11 77 / Currently at Scandinavian Airline Systems =======/ UUCP: andrew@resam.dk, phone: +45 32 32 51 54 \ SAS, RESAM Project Office, CPHML-V, P.O.BOX 150, DK-2770 Kastrup, Denmark > > Read oe as: o <backspace> / (slash) and OE as O <backspace> / (slash) < <
tj@Alliant.COM (Tom Jaskiewicz) (01/12/91)
In article <10852@darkstar.ucsc.edu> funkstr@ucscb.UCSC.EDU (Larry Hastings) writes: >This makes this example somewhat less compelling -- if you had a program >which was legal both ways and produced different output, I'd be more >inclined to agree. (I can't come up with such an example -- does anyone have >one?) Ok... How about this: int foo(int a, int b) { return a //* what kind of comment is this? */ 2 //* what kind of comment is this? */ -b; } Not that I normally write code that looks like that. -- ########################################################################## # The doctrine of nonresistance against arbitrary power, and oppression is # absurd, slavish, and destructive of the good and happiness of mankind. # -- Article 10, Part First, Constitution of New Hampshire
thornley@cs.umn.edu (David H. Thornley) (01/12/91)
In article <628@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: >In article <1991Jan08.192415.3361@grep.co.uk> frank@grep.co.uk (Frank Wales) writes: >>>[Referring to the "//" comment indicator, and finding the end of >>> the comment.] >| >|My editor doesn't have a 'search for text in printouts' function. Does yours? > >Actually, I considered this point when I was making the original post. The >reason I decided it wasn't important is that I can't imagine doing any serious >work on a program when only hardcopy is available. (*Surely* there is an >on-line copy somewhere!) My, how things change. I can think of several reasons for working off hardcopy: 1. The large-screen multiple-window terminals are not available for some reason, and you're stuck with a 24-line tube (like I'm using right now). 2. The source was never made available on-line, and you want to look at it without typing it in. 3. The source is available, but not in the right format, or not immediately, or something. 4. You want to sit out under a tree or in bed and consider the code. 5. You aren't doing serious work, and therefore find it annoying to have to search for where the comment ends. 6. You're reading a book, not hacking code. Shall I start the story about writing the multiple-precision arithmetic routines in Z80 assembler on a TRS-80 Mod I (16 line screen) with a four-inch-carriage thermal printer or are you willing to concede that useful work can be done under adverse conditions? DHT
steve@taumet.com (Stephen Clamage) (01/13/91)
andrew@resam.dk (Leif Andrew Rump) writes: >Just a single question: Does TC warn you about comment (/*) inside >a comment (//)? If not then _I_ will never mix // and /**/ and maybe >even abandon // completely!!! Comments do not nest. A // introduces a comment which extends *to* (not through) the end of the line. There is no problem in mixing the two styles. For example: // foo(bar); /* I'm not sure if I want this call */ The entire line can be commented out by placing the // at the start, and has no effect on any other code in the program. Similarly: /* foo(bar); // for foo-ish systems fee(fie); // for foo-ish or fee-sh systems */ The two line can be commented out with the /* */ even though they contain //-style comments. A consistent commenting style is helpful. I use // for trailing inline comments, and /* */ for block comments. -- Steve Clamage, TauMetric Corp, steve@taumet.com
steve@taumet.com (Stephen Clamage) (01/13/91)
thorinn@diku.dk (Lars Henrik Mathiesen) writes: >brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: ><Then you have a push-pull in the preprocessor between the #define, which ><takes everything up to the next newline, and the //, which takes ><everything up through the next newline. I'd say the #define should win... >If the #define wins, // comments cannot be used as line continuations >in macros. Pity, because I liked your idea of merging the comment and >continuation mechanisms. // comments extend *to* the end of the line, not through it. They cannot be used as line continuations. So #define foo bar // use bar instead of foo blah blah is equivalent to #define foo bar blah blah You also cannot use line continuation in the presence of // comments, because the ANSI "phases of translation" apply. The line continuation is applied before comments are recognized, and everything past the // is lost. #define foo // comment here \ bar first becomes #define foo // comment here bar and then becomes #define foo which presumably is not what was intended. NOTE: Not all existing preprocessors treat // comments the same way. What I have stated above is as specified in the latest documentation for C++. Some existing (older) C++ compilers behave differently. For C, // comments are an extension, not part of any standard, so who knows what different compilers will do? -- Steve Clamage, TauMetric Corp, steve@taumet.com
henry@zoo.toronto.edu (Henry Spencer) (01/13/91)
In article <1991Jan08.164014.26804@sco.COM> ron@scocan.sco.COM (Ron Irvine) writes: > | ... the characters /* introduce a comment. The contents of > | a comment are examined only to identify multibyte characters > | and to find the characters */ that terminate it. 26 > >Thus, a compiler that gives a warning of nested comments upon >finding the characters /* within a comment must have "examined" >the contents of the comment beyond that specified by the standard >and is in violation of the standard... Sorry, wrong. The standard defines the *language*, not the implementation. What that section says is that the contents of a comment cannot influence whether a program is legal, and cannot change the semantics of the program's execution. Warning messages are outside the scope of the standard entirely. Indeed, if you examine Appendix E, you will find an explicit suggestion that compilers might produce such a warning. -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
gwyn@smoke.brl.mil (Doug Gwyn) (01/13/91)
In article <4427@alliant.Alliant.COM> tj@Alliant.COM (Tom Jaskiewicz) writes: >//* what kind of comment is this? */ Not to pick on Tom, but this discussion is a real waste of time. (a) // comments are not supported in Standard C, having been proposed to X3J11 and rejected after committee discussion. Therefore this is the wrong newsgroup to be discussing them in. Isn't there some sort of "future C proposals" group? Or, use the C++ newsgroup. (b) All questions about how to parse // comments would presumably be resolved by defining their role in the "phases of translation". Without such a definition, such questions have no unambiguous answers. With such a definition, there is nothing to discuss.
gwyn@smoke.brl.mil (Doug Gwyn) (01/13/91)
In article <550@taumet.com> steve@taumet.com (Stephen Clamage) writes: >/* > foo(bar); // for foo-ish systems > fee(fie); // for foo-ish or fee-sh systems >*/ >The two line can be commented out with the /* */ even though they contain >//-style comments. By the way, when I include commented usage examples in my C source code I use //-comments much as in the above example, because /*...*/ comments do not nest and within /*...*/ comments //-comments do not break anything whether the C compiler supports //-comments or not.
sking@nowhere.uucp (Steven King) (01/14/91)
In article <551@taumet.com> steve@taumet.com (Stephen Clamage) writes: >NOTE: Not all existing preprocessors treat // comments the same way. >What I have stated above is as specified in the latest documentation >for C++. Some existing (older) C++ compilers behave differently. >For C, // comments are an extension, not part of any standard, so who >knows what different compilers will do? >-- Microsoft C, surprisingly enough, handles this correctly, while pcc's cpp ignores the // so that #define RDR 1 // reader x = y[RDR] ; is expanded to x = y[1 // reader] resulting in a very frustrating source of error messages from cfront. This is a problem with most implementations of cfront that dont supply their own cpp and even with a few that do. ( the LPI c compiler, which claims to be ANSI, ignores _//_, and barfs at things like _#ident_ and most everything else ) -- ..!cs.utexas.edu!ut-emx!nowhere!sking been dazed and confused for so long its true; wanted an OS, never bargined for you. Lotsa people hacking, few of them know, kernal of unix was created below...
karl@ima.isc.com (Karl Heuer) (01/15/91)
In article <1991Jan08.164014.26804@sco.COM> ron@scocan.sco.COM (Ron Irvine) writes: >[The code fragment "a = 100/*p /* calculate first factor */" was compiled >with no warning on four diferent compilers, one of which was gcc.] gcc does indeed flag this, provided you have the warnings enabled with -Wall. I strongly recommend using this option, and avoiding those coding styles% that violate the assumptions it uses. (In fact, I normally compile my own code with gcc -Wall -Wcast-qual -Wwrite-strings, and lint it as well.) Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint ________ % In particular, the (legal but questionable) /*#define BSD 1 /* uncomment this line for BSD systems */
bright@nazgul.UUCP (Walter Bright) (01/15/91)
In article <4423@alliant.Alliant.COM> tj@Alliant.COM (Tom Jaskiewicz) writes:
<If you do add // comments to c, what does the following code do?
</* printf("One\n"); /* 1 */
< printf("Two\n"); /* 2 */
</* printf("Three\n");
<// printf("Four\n"); /* 4 */
< printf("Five\n"); /* 5 */
<// printf("Six\n"); /* 6
< printf("Seven\n"); /* 7 */
</* printf("Eight\n");
<// */ printf("Nine\n");
< printf("Ten\n"); /* 10 */
Removing commented out structures we get:
printf("Two\n");
printf("Five\n");
printf("Seven\n");
printf("Nine\n");
printf("Ten\n");
No problem. The rules to remember are:
o When inside a comment, the only thing recognized is an end-of-comment
for the type of comment you're inside. If you're in a /* comment,
characters are eaten until you see a */. If you're in a //
comment, characters are eaten until you see a newline.
o As a corollary, comments do not nest.
o Backslashes \ that terminate a line are removed and lines are
spliced *before* comment processing is done. (Anything else would
cause a major monkey wrench into the ANSI C phases of translation
verbage.) This means that:
a = b; // this \
text is part of the comment!
a = b; /\
/ this text is a comment!
a = b; /* *\
/ "this text is not part of a comment!";
The idea behind \ line splicing is that it can be done in a very
simple context-free manner.burley@geech.ai.mit.edu (Craig Burley) (01/16/91)
In article <22@christmas.UUCP> rtm@christmas.UUCP (Richard Minner) writes:
...to keep this wonderous thread going (anyone keeping count?) there's
another really super big advantage of // that I haven't seen mentioned.
If you want to write a header for a function or file and include
an example of usage that actually looks like regular code with
normal comments, you can't do it with /* */ without resorting
to some pretty ugly guck with #if/#endif. With // it's trivial.
Yes, I use // in just that way. The neat thing is, the compiler doesn't
have to support // as a comment delimiter! (Of course, that means the
example won't QUITE look "like regular code with normal comments"...but
it sure beats using /* without a closing */!)
--
James Craig Burley, Software Craftsperson burley@ai.mit.edupreston@LL.MIT.EDU (Steven Preston) (01/18/91)
In article <1991Jan08.164014.26804@sco.COM> ron@scocan.sco.COM (Ron Irvine) writes: >[quote of ANSI C Section 3.1.9] >Thus, a compiler that gives a warning of nested comments upon >finding the characters /* within a comment must have "examined" >the contents of the comment beyond that specified by the standard >and is in violation of the standard. Section 3.1.9 specifies a semantic constraint. A translator which examines the contents of a comment in more detail is not in "violation" of the standard. Section 1.6 "Definitions of Terms" starts: In this standard, ``shall'' is to be interpreted as a requirement on an implementation or on a program; conversely, ``shall not'' is be interpreted as a prohibition. Since 3.1.9 does not contain the words ``shall not'', it does not constitute a prohibition. -- Steve Preston
gwyn@smoke.brl.mil (Doug Gwyn) (01/20/91)
In article <18701:Jan1916:03:2691@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Why can't people get together here and discuss how (and if) to propose >// to ANSI for the next revision of the standard? Several points: I understand that there is another newsgroup for such discussions. People proposing // seem unaware that this has already been considered and rejected for the C standard. No arguments have been made that would justify reopening the issue. It will be several years before the ANSI C committee will be soliciting public comment for the next revision of the C standard. Thus this newsgroup is not presently a useful place for such discussions.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/21/91)
In article <14906@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: > In article <18701:Jan1916:03:2691@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Why can't people get together here and discuss how (and if) to propose > >// to ANSI for the next revision of the standard? > Several points: > I understand that there is another newsgroup for such discussions. Ah, so you're saying that before ANSI C was approved, it was a future language, and hence discussions of it should have taken place on Peter's cfutures mailing list (now alt.lang.cfutures). As should all discussions of C++, which is one direction of the future of C. Right? > People proposing // seem unaware that this has already been considered > and rejected for the C standard. No arguments have been made that > would justify reopening the issue. Really? I can believe that the committee rejected // because it hasn't been used too much in implementations. But that's changing. The argument about commenting out an already partially commented-out section of code shows that // has at least one objective advantage which even cynics like you can't dispute. > It will be several years before the ANSI C committee will be soliciting > public comment for the next revision of the C standard. Thus this > newsgroup is not presently a useful place for such discussions. Ah. So when is the magic deadline for making this group useful again? And since when is ``standard'' synonymous with ``ANSI''? Why can't we chat about IBM Standard C here if we want? ---Dan
karl@ima.isc.com (Karl Heuer) (01/21/91)
In article <936@hadron.COM> jsdy@hadron.UUCP (Joseph S. D. Yao) writes: >I got code [containing "//" comments] from [somewhere] some 12-15 years ago >(was that you, Karl? since you claimed to be first) No, I wasn't the first; I merely reinvented the idea before knowing about the related implementations (BCPL and C++). But I never wrote any code that way. (I did once experiment with having my own preprocessor, and I think I wrote a handful of programs using it, but I quickly abandoned that in favor of writing portable code.) >It was the devil to get out so that a "real" (from Ken & Dennis' pen) C >compiler could compile it. The point is, if it's not in C, don't use it. Exactly. Though I'm willing to bend the rules for stuff that can be simulated without too much trouble: I used void before it was universally available, since a simple typedef suffices to make it acceptable to voidless compilers; I write new code with prototypes, using a style that my deprotoizer can parse. Since I have a tool that knows the lexical structure of C and C++, I wouldn't hesitate to start using "//" comments immediately if I thought they'd be part of standard C in the near future. Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
gwyn@smoke.brl.mil (Doug Gwyn) (01/22/91)
In article <24885:Jan2017:05:1091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Why can't we chat about IBM Standard C here if we want? Because we set up this newsgroup specifically for the purpose of discussing the (then forthcoming) ANSI C standard. If you want to turn it into a general C blather group, then I'll simply unsubscribe. People with serious questions about the C standard generally send me direct e-mail anyway.
jsdy@hadron.COM (Joseph S. D. Yao) (01/27/91)
In article <24885:Jan2017:05:1091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >And since when is ``standard'' synonymous with ``ANSI''? Why can't we >chat about IBM Standard C here if we want? (a) The American National Standards Institute - ANSI - is so chartered. (b) Using Itty Blue Monster Co.'s name in the same phrase as "Standard" is an oxymoron. That company doesn't follow standards: it makes up its own ways of doing things so it can change them as often as it feels like. Which year's version of EBCDIC are you writing your notes with? - These opinions are shared by millions, but generated here only by - myself and not by any other person(s) or organisation(s). Joe the Intransigent Transient
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (01/28/91)
[This one's drifted away from C standardization...replies {and the flames
I know I'll get for defending (horrors!) IBM} via E-mail, please. I simply
couldn't let it go unchallenged.]
In article <937@hadron.COM> jsdy@hadron.UUCP (Joseph S. D. Yao) writes:
>(b) Using Itty Blue Monster Co.'s name in the same phrase as "Standard"
>is an oxymoron. That company doesn't follow standards: it makes up its
>own ways of doing things so it can change them as often as it feels
>like. Which year's version of EBCDIC are you writing your notes with?
IBM's stuff is as much a standard in the world of DP - you know, such mundane
things as payrolls, accounts payable, and the like - as Unix is in the world
of academic computing. Whether or not you like it, it's still the truth.
Oh, yeah - EBCDIC hasn't changed in at least the 11 years I've dealt with it.
Which year's version of ASCII are _you_ writing your notes with?
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity.
"Today is different from yesterday." -- State Department spokesman Margaret
Tutwiler, 17 Jan 91, explaining why they won't negotiate with Saddam Husseinjamiller@hpcupt1.cup.hp.com (Jim Miller) (02/05/91)
>I got code ... >that used the "// ..." style of comment. It was the devil to get out >so that a "real" (from Ken & Dennis' pen) C compiler could compile it. "It was the devil to get out" ... ?!? Ever hear of sed? How about AWK? Just eliminate the comment's contents. If you need to keep the comments in the source, sed/awk as an additional pre-processor step in your makefile should do the trick. Granted, there might be cases where // might be in a literal, but a quick look with fgrep should find those for you and then take additional action (in a awk script). O.K., so what am I so stupid that I'm not seeing? jim - ??? - miller jamiller@hpmpeb7.cup.hp.com (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... ) Anything I say will be used against me ... But my company doesn't know or approve or condone anything of mine here.
gwyn@smoke.brl.mil (Doug Gwyn) (02/06/91)
In article <-286619997@hpcupt1.cup.hp.com> jamiller@hpcupt1.cup.hp.com (Jim Miller) writes: >Granted, there might be cases where // might be in a literal, but >a quick look with fgrep should find those for you and then take additional >action (in a awk script). >O.K., so what am I so stupid that I'm not seeing? // may also be in a /*...*/ comment. I once wrote a utility to de-// such source code; it implemented an FSA and had something like twenty states as I recall. It wasn't trivial but it also wasn't all that difficult.