chris@wacsvax.OZ (chris mcdonald) (02/16/90)
raw@math.arizona.edu (Rich Walters) writes: >In article <236100027@prism> ly@prism.TMC.COM writes: >> >> I'm just curious to know why nested comments are not allowed in many >> languages. >Nested comments are not supported because it is difficult to tell where the >nesting ends. Have you ever written a paren checker in C? (in any language?) >Reason 2) Why waste the computing power?? After all, it's only a comment!! What a stupid response! I don't know why they are not supported but agree that they are damn useful. They are easy to parse in syntactically correct programs (ever heard of counting?) and, after all, the computer/compiler is supposed to do what we tell it, not for us to bow down and minimize its work. If its really too hard for you to count comments I'll sell you a little parser for a ridiculous amount. -------------------------------------------------------------------------------- Chris McDonald. Department of Computer Science, ACSnet: chris@wacsvax.oz University of Western Australia, ARPA: chris%wacsvax.oz@uunet.uu.net Mounts Bay Road, UUCP: ..!uunet!murtoa!wacsvax!chris Crawley, Western Australia, 6009. SDI: (31.97 +/-10% S, 115.81 +/-10% E) PHONE: ((+61) 09) 380 2533 FAX: ((+61) 09) 382 1688
shoe@hpcllak.HP.COM (Jim "Shoe" Schumacher) (02/17/90)
>ly@prism.TMC.COM / 8:21 am Feb 14, 1990 / > > I'm just curious to know why nested comments are not allowed in many > languages. >---------- You can have some subtle errors with nested comments. ____ { this was a real **{??/ to write and ..... <- start of nesting } <- rest of the file is ignored while we search for the matching brace and the compiler ends up giving you some really strange error message about unexpected eof. You go through your code and can't figure out what it's complaining about. ____ When nesting is allowed you can no longer place any characters you want in your comments since your text is being scrutinized by the compiler. The need to nest comments usually arises when you want to comment out a section of code that contains comments. A better way to do this is to use a compiler directive like #ifdef. ------ #ifdef 0 code with comments.... #endif jim shoe (shoe@hpda)
dalenber@cbnewsc.ATT.COM (Russel Dalenberg) (02/18/90)
In article <1523@wacsvax.OZ>, chris@wacsvax.OZ (chris mcdonald) writes: > I don't know why they are not supported but agree that they are damn > useful. They are easy to parse in syntactically correct programs (ever > heard of counting?) and, after all, the computer/compiler is supposed to > do what we tell it, not for us to bow down and minimize its work. > If its really too hard for you to count comments I'll sell you a little > parser for a ridiculous amount. And what will you do when trying to comment out code that contains the "end of comment" sequence? printf("A comment is ended with */"); Russel Dalenberg att!ihlpb!dalenber dalenber@ihlpb.att.com
utoddl@uncecs.edu (Todd M. Lewis) (02/19/90)
In article <7330017@hpcllak.HP.COM> shoe@hpcllak.HP.COM (Jim "Shoe" Schumacher) writes: >>ly@prism.TMC.COM / 8:21 am Feb 14, 1990 / >> I'm just curious to know why nested comments are not allowed in many >> languages. >You can have some subtle errors with nested comments. You can have subtle errors with "flat" comments. ready_level = FULL_ALLERT; /* Can't disarm except in this state * / status = disarm_missle(); /* who would have thought it could happen! */ Look closely at the comment. Yes, there's only one comment. If the compiler had supported nested comments, this wouldn't have compiled, run, and "bombed". >{ > this was a real **{??/ to write and ..... <- start of nesting >} ><- rest of the file is ignored while we search for the matching brace > and the compiler ends up giving you some really strange error message > about unexpected eof. You go through your code and can't figure out > what it's complaining about. You have a broken tool. Any compiler worth its salt should tell you where an unclosed comment begins. Everybody knows where it ends. Claiming nested comments are no good because your compiler doesn't know how to handle them doesn't hold water. That would be as bad as not telling you what #ifdef wasn't #endif'd (see comment below). Or for that matter, it's as bad as not dealing with improperly nested { }. >When nesting is allowed you can no longer place any characters you want >in your comments since your text is being scrutinized by the compiler. You can't do that now--at least you can't put "*/" in. >The need to nest comments usually arises when you want to comment out >a section of code that contains comments. A better way to do this is >to use a compiler directive like #ifdef. >#ifdef 0 > code with comments.... >#endif Because we've been doing it that way for eons doesn't mean it's a "better way." Of course, without true nested comments it's the only way, but that, too, is beside the point. #ifdef/#endif is better for conditionally compiling code fragments. Nested comments are the better way to "comment out a section of code that contains comments." Your own words--it should be obvious. I am continually amazed that the C community, which claims a plethora of operators is good and that professionals should be able to handle them, which can nest {}, [], (), and #ifdef/#endif in myriad ways, which declares pointers safe if used by responsible programmers, could be intimidated by the concept of something as benign, useful, and elegent as nested comments. Sounds like a lot of NIH to me. Sure, nesting of comments can be accomplished with #ifdef/#endif. So what? while and for can be accomplished with goto. But it's the wrong tool. >jim shoe (shoe@hpda) Please don't read this as a personal attack on Jim. He just hit a nerve. -- Todd M. Lewis
remmers@emunix.emich.edu (John H. Remmers) (02/20/90)
In article <1990Feb19.143619.17663@uncecs.edu> utoddl@uncecs.edu (Todd M. Lewis) writes: >In article <7330017@hpcllak.HP.COM> shoe@hpcllak.HP.COM (Jim "Shoe" Schumacher) writes: ... >>You can have some subtle errors with nested comments. > >You can have subtle errors with "flat" comments. Considering the subtle and potentially dangerous errors possible with both nested and unnested comments, I've about decided that I prefer end-of-line-only comments, a la Ada. Or are subtle errors possible here too? -- John H. Remmers | Internet: remmers@emunix.emich.edu Eastern Michigan University| UUCP: {ames,rutgers}!mailrus!clip!emunix!remmers Dept. of Computer Science | voice:(313) 487-1225
schaut@cat9.cs.wisc.edu (Rick Schaut) (02/20/90)
In article <1523@wacsvax.OZ> chris@wacsvax.OZ (chris mcdonald) writes: | raw@math.arizona.edu (Rich Walters) writes: | >Nested comments are not supported because it is difficult to tell where the | >nesting ends. Have you ever written a paren checker in C? (in any language?) | | >Reason 2) Why waste the computing power?? After all, it's only a comment!! | | What a stupid response! | I don't know why they are not supported but agree that they are damn | useful. They are easy to parse in syntactically correct programs (ever | heard of counting?) and, after all, the computer/compiler is supposed to | do what we tell it, not for us to bow down and minimize its work. | If its really too hard for you to count comments I'll sell you a little | parser for a ridiculous amount. I think you've missed the point. In compilers for languages that do not allow nested comments the parser never see the comment at all. The comments are eaten by the scanner (which is a much simpler part of the compiler than is a parser). Essentially, any language that requires balancing characters (e.g. the language of balanced parens) cannot be represented using regular expressions, and regular expressions are the construct upon which scanners are based. In short, a compiler for a language that doesn't allow nested comments is _much_ faster than a compiler for a language that allows them. Pick up a copy of _Compilers: Principles, Techniques and Tools_ by Aho Sethi & Ullman for a more comprehensive explanation. -- Rick (schaut@garfield.cs.wisc.edu) Peace and Prejudice Don't Mix! (unknown add copy)
mike@cs.arizona.edu (Mike Coffin) (02/20/90)
From article <4320@daffy.cs.wisc.edu>, by schaut@cat9.cs.wisc.edu (Rick Schaut): > I think you've missed the point. In compilers for languages that do not > allow nested comments the parser never see the comment at all. The comments > are eaten by the scanner (which is a much simpler part of the compiler than > is a parser). Essentially, any language that requires balancing characters > (e.g. the language of balanced parens) cannot be represented using regular > expressions, and regular expressions are the construct upon which scanners > are based. In short, a compiler for a language that doesn't allow nested > comments is _much_ faster than a compiler for a language that allows them. The last sentence doesn't follow from the rest of the paragraph. Scanners may be *based* on regular expressions, but the popular scanners (Lex, Flex, and friends) are not *restricted* to regular expressions. In fact, as people often have pointed out, parsing comments with regular expressions can be dangerous with some scanners because long comments will overflow fixed-sized buffers. A common work-around is to detect the beginning of a comment by a regular expression and call a function (in C, perhaps) to eat the rest of the comment. This avoids the buffer-overflow problems and makes it trivial to parse nested comments---just count the number of <begin-comment> tokens and match them with <end-comment> tokens. Nothing slow about that. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike Tucson, AZ 85721 (602)621-2858
bethge@wums.wustl.edu (02/20/90)
In article <1990Feb19.143619.17663@uncecs.edu>, utoddl@uncecs.edu (Todd M. Lewis) writes: > ... Because we've been doing it that way for eons doesn't mean it's a > "better way." Of course, without true nested comments it's the > only way, but that, too, is beside the point. #ifdef/#endif is better ^^^^^^^^^^^^^^^^^^^^^^^ > for conditionally compiling code fragments. Nested comments are the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > better way to "comment out a section of code that contains comments." > Your own words--it should be obvious. I am continually amazed that > the C community, which claims a plethora of operators is good and that > professionals should be able to handle them, which can nest {}, [], (), > and #ifdef/#endif in myriad ways, which declares pointers safe if used by > responsible programmers, could be intimidated by the concept of something > as benign, useful, and elegent as nested comments. Sounds like a lot of > NIH to me. > Sure, nesting of comments can be accomplished with #ifdef/#endif. So what? > while and for can be accomplished with goto. But it's the wrong tool. This apprears to be a religious issue. It is not the least bit "obvious" to me that "nested comments are the better way" to suppress the compilation of a section of code. What is this, if not conditional compilation? ____________________________________________________________________________ Paul H. Bethge bethge@wums.wustl.edu Biochemistry, Box 8231 bethge@wums.bitnet Washington University St. Louis, MO 63110 314-362-3354
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (02/20/90)
>In article <1523@wacsvax.OZ>, chris@wacsvax.OZ (chris mcdonald) writes: >> I don't know why they are not supported but agree that they are damn >> useful. They are easy to parse in syntactically correct programs (ever >> heard of counting?) In article <13706@cbnewsc.ATT.COM> dalenber@cbnewsc.ATT.COM (Russel Dalenberg) writes: >And what will you do when trying to comment out code that contains the >"end of comment" sequence? > printf("A comment is ended with */"); Oh, come on... this is no problem. My kids in "Intermediate Programming" wrote this for their FIRST assignment in C. It is easy to construct the necessary automaton if you aren't counting nest levels, and not hard to add the nesting. Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
friedl@mtndew.UUCP (Steve Friedl) (02/20/90)
Three different people have noted:
1> You can have some subtle errors with nested comments.
2> You can have subtle errors with "flat" comments.
3> Considering the subtle and potentially dangerous errors possible
3> with both nested and unnested comments, I've about decided that
3> I prefer end-of-line-only comments, a la Ada. Or are subtle
3> errors possible here too?
Compelling arguments all: perhaps it is safest not to comment at all?
Steve :-)
P.S. - Some people I know must have >mighty< reliable code...
--
Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy
+1 714 544 6561 voice / friedl@vsi.com / {uunet,attmail}!mtndew!friedl
"Winning the Balridge Quality Award is as easy as falling off a horse." - meutoddl@uncecs.edu (Todd M. Lewis) (02/21/90)
[Sorry, folks. I started this, now I'll try to end it. Sure...] In article <1975.25e0048c@wums.wustl.edu> bethge@wums.wustl.edu writes: >In article <1990Feb19.143619.17663@uncecs.edu>, utoddl@uncecs.edu >(Todd M. Lewis) writes: >> ... Because we've been doing it that way for eons doesn't mean it's a >> "better way." Of course, without true nested comments it's the >> only way, but that, too, is beside the point. #ifdef/#endif is better > ^^^^^^^^^^^^^^^^^^^^^^^ >> for conditionally compiling code fragments. Nested comments are the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> better way to "comment out a section of code that contains comments." >> Your own words--it should be obvious. I am continually amazed that [lots of wonderful logic deleted] > >This apprears to be a religious issue. It is not the least bit "obvious" to >me that "nested comments are the better way" to suppress the compilation of >a section of code. What is this, if not conditional compilation? You have quite precisely missed my point. It was even in quotes. Briefly: 1) "comment out a section..." Use comments. 2) "compile if x {not} defined" Use #if{n}def/#endif. See the difference? In particular, I did not say that nested comments are the better way to suppress the compilation of a section of code. If it's a comment it isn't code! The notion of conditionally compiling comments is a bit off the mark, IMHO. Comments are never compiled--nothing conditional about that. Lexed or parsed maybe, but not compiled. It isn't a religious issue. It is a semantic issue--on two levels, no less. On the lower level, what I said is not what you thought I meant. On the higher level, #ifdef/#endif and nested comments are not the same although the end result may be the same. _____ | Todd M. Lewis Disclaimer: If you want my employer's ||\/| utoddl@ecsvax.uncecs.edu ideas, you'll have to || || utoddl@ecsvax.bitnet, @unc.bitnet _buy_ them. | || utoddl@sun1.mscre.unc.edu |___ ("Prgrms wtht cmmnts r lk sntncs wtht vwls." --TML)
tjo@its.bt.co.uk (Tim Oldham) (02/21/90)
In article <4320@daffy.cs.wisc.edu> schaut@cat9.cs.wisc.edu (Rick Schaut) writes: > >I think you've missed the point. In compilers for languages that do not >allow nested comments the parser never see the comment at all. The comments >are eaten by the scanner (which is a much simpler part of the compiler than >is a parser). Essentially, any language that requires balancing characters >(e.g. the language of balanced parens) cannot be represented using regular >expressions, and regular expressions are the construct upon which scanners >are based. In short, a compiler for a language that doesn't allow nested >comments is _much_ faster than a compiler for a language that allows them. In a Modula-2 interpreter I was once involved with, the scanner simply matched the first start_of_comment and then called eat_nested_comment(), and extremely simple and fast recursive routine. This also allowed the start of the comment to be printed if an error occurred ie unmatching close-comments. As you're throwing away everything in between the beginning and end of the outermost comments, it's a completely different category of problem. The parser never sees any of the comment. In fact, you can guarantee that the main scanner token-matcher will only ever see an outermost start_of_comment. You never generate any tokens for the parser. Tim. -- Tim Oldham, BT Applied Systems. tjo@its.bt.co.uk or ...!ukc!axion!its!tjo ``Asking questions is the best way to get answers.'' --- Philip Marlowe.
dfoster@jarthur.Claremont.EDU (Derek R. Foster) (02/21/90)
>In article <13706@cbnewsc.ATT.COM> dalenber@cbnewsc.ATT.COM (Russel Dalenberg) writes: >>And what will you do when trying to comment out code that contains the >>"end of comment" sequence? >> printf("A comment is ended with */"); Maybe I'm just strange, but I think that this whole issue of "what will you do if your code contains start/end comment characters" is missing an important point. It seems to me that putting a start or end comment in a string literal (like above) is a HORRIBLE programming practice whether you can have nested comments or not. It's just asking to be accidentally matched with some other part of a comment. Couldn't you avoid the whole issue by just doing something like : printf("A comment is ended with *\/"); (I'm not sure if this is portable) or else you could just go printf("A comment is ended with *""/"); or else, as a last resort, printf("A comment is ended with *%c",'/'); These don't seem like too much trouble given the relatively few times you will ever need to do this, and they will not only save you from problems with nested comments (now, your code doesn't care), it will also save you from potentially forgetting to close one of your comments, only to have it matched somewhere you didn't expect... Just my 2c. Derek Foster
dalenber@cbnewsc.ATT.COM (Russel Dalenberg) (02/21/90)
In article <4286@jhunix.HCF.JHU.EDU>, barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: > In article <13706@cbnewsc.ATT.COM> dalenber@cbnewsc.ATT.COM (Russel Dalenberg) writes: >>And what will you do when trying to comment out code that contains the >>"end of comment" sequence? >> printf("A comment is ended with */"); > > Oh, come on... this is no problem. My kids in "Intermediate > Programming" wrote this for their FIRST assignment in C. It is easy to > construct the necessary automaton if you aren't counting nest levels, > and not hard to add the nesting. Fine, then enlighten me. Remember, that quotes have *NO* significance in comments, so you can't discard the "*/" above because it's inside quotes. Russel Dalenberg att!ihlpb!dalenber dalenber@ihlpb.att.com Disclaimers: These opinions are mine, all mine!
sanders@sanders.austin.ibm.com (Tony Sanders) (02/21/90)
In article <1990Feb20.165353.14212@uncecs.edu> utoddl@uncecs.edu (Todd M. Lewis) writes: >See the difference? In particular, I did not say that nested comments are >the better way to suppress the compilation of a section of code. If it's a >comment it isn't code! The notion of conditionally compiling comments is >a bit off the mark, IMHO. Comments are never compiled--nothing conditional >about that. Lexed or parsed maybe, but not compiled. > It isn't a religious issue. It is a semantic issue--on two levels, no less. >On the lower level, what I said is not what you thought I meant. On the >higher level, #ifdef/#endif and nested comments are not the same although >the end result may be the same. It is semanticly different but that doesn't exclude it from being a religious issue. The simple fact is I don't have to use /**/ comments at all and I can still comment my code. It's a preference and therefore a religious issue, /**/'s don't nest, while #if's do. Choose which one you want for what you are doing. If the end result is EXACTLY the same you are in the realm of religion. It's the issues that don't have the same result that are the tuffies. This will give all those stupid people in alt.religion.computers something new to fight about (see you there :-). -- sanders JUST SAY kNOw TO DRUGS Reply-To: cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders "she was an innocent bystander, it's a democracy" -- Jim Morrison
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (02/21/90)
In article <4509@jarthur.Claremont.EDU> dfoster@jarthur.Claremont.EDU (Derek R. Foster) writes: >It seems to me that putting a start or end >comment in a string literal (like above) is a HORRIBLE programming practice >whether you can have nested comments or not. Oh yes? Well, what if you are writing a C program that generates C code as its output? This is a common practice. Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
leoh@hardy.hdw.csd.harris.com (Leo Hinds) (02/21/90)
schaut@cat9.cs.wisc.edu (Rick Schaut) writes: > ... In short, a compiler for a language that doesn't allow nested >comments is _much_ faster than a compiler for a language that allows them. That is probably true ... but if I remember correctly TC allows you to use nested comments (If you tell it to let you) ... and yet TC is not all that slow. leoh@hdw.csd.harris.com H H i d sssss L eeeee oooo H H nnnn ddddd ss L eee o o HHHHHH i n n d d ss LLLLLL eeeee oooo H H i n n ddddd sssss
bethge@wums.wustl.edu (02/22/90)
In article <1990Feb20.165353.14212@uncecs.edu>, utoddl@uncecs.edu (Todd M. Lewis) writes: > You have quite precisely missed my point. It was even in quotes. Briefly: > 1) "comment out a section..." Use comments. > 2) "compile if x {not} defined" Use #if{n}def/#endif. > See the difference? In particular, I did not say that nested comments are > the better way to suppress the compilation of a section of code. If it's a > comment it isn't code! The notion of conditionally compiling comments is > a bit off the mark, IMHO. Comments are never compiled--nothing conditional > about that. Lexed or parsed maybe, but not compiled. > It isn't a religious issue. It is a semantic issue--on two levels, no less. > On the lower level, what I said is not what you thought I meant. On the > higher level, #ifdef/#endif and nested comments are not the same although > the end result may be the same. OK, I am not understanding you. Can you enlighten me? My question is, *why* do you want nested comments? I asked this question in a previous posting, to which no one responded. As I said then, the only use I can think of is to suppress the compilation of a section of code (containing comments), by turning it into a comment. This is what I understand to be the meaning of the phrase "comment out a section...". I know that the *mechanisms* of #ifdef/#endif and nested comments are different. But if the *purpose* is the same, and the *end result* is the same, why are both needed? Do you object the the introduction of a bogus undefined identifier, as in #ifdef YES_COMPILE_THIS_HERE_BIT_OF_HACKWORK . . . #endif or what? Or is there really some other use for nested comments? If there is, I don't want to remain ignorant of it. No sarcasm intended. I really am seeking enlightenment. _______________________________________________________________________ Paul H. Bethge bethge@wums.wustl.edu Biochemistry, Box 8231 bethge@wums.bitnet Washington University St. Louis, MO 63110 314-362-3354
misu_ss@uhura.cc.rochester.edu (What`s in a name?) (02/22/90)
In article <4292@jhunix.HCF.JHU.EDU> barrett@jhunix.UUCP (Dan Barrett) writes: >In article <4509@jarthur.Claremont.EDU> dfoster@jarthur.Claremont.EDU (Derek R. Foster) writes: >>It seems to me that putting a start or end >>comment in a string literal (like above) is a HORRIBLE programming practice >>whether you can have nested comments or not. > > Oh yes? Well, what if you are writing a C program that generates >C code as its output? This is a common practice. > This leads me to a question on how compilers work... Do #defines get worked out before comments are discarded... I.E. if I write code thus: #define OPEN_COMMENT "/*" #define CLOSE_COMMENT "*/" main() { char *string[30] string = OPEN_COMMENT; printf("s% ", string); string = "This is a C comment"; printf("s% ", string); string = CLOSE_COMMENT; printf("s%\n", string); } will this produce the output: /* This is a C comment */ or will it simply do a newline and make string point to the return value of printf? (likely causing a seg fault if string is ever assigned again...) On gcc version 1.36 and cc (don't know version) running under SunOS4.0.3 this code produces the first output. Any compilers out there that do comment checking after filling out macros? If this always works then this is a possible solution to the problem... Obviously, you'll have to use string functions but is that so bad? If you are doing something that will output C code it's going to be pretty general in nature... There won't be a lot of cases where constant output is easiner than variable output. --mike -- Mic3hael Sullivan, Society for the Incurably Pompous -*-*-*-*- ...I know there are people in the world who do not love their fellow human beings and I *HATE* people like that! --Tom Lehrer
news@ism780c.isc.com (News system) (02/22/90)
In article <2037.25e266bf@wums.wustl.edu> bethge@wums.wustl.edu writes: >OK, I am not understanding you. Can you enlighten me? My question is, >*why* do you want nested comments? ... >I know that the *mechanisms* of #ifdef/#endif and nested comments are >different. But if the *purpose* is the same, and the *end result* is >the same, why are both needed? Not that it is important but #if/#endif cannot be used to 'comment out' starting in the middle of a line and/or ending at the middle of a line. Actually, when I 'comment out' it is always for debugging. In almost every instance, I also 'comment in' a piece of code. The method I use (in Unix) is: cp foo.c foo.c.sav <munch on foo.c with the editor of my choice> cc foo.c <try the program> mv foo.c.sav foo.c This is extemely flexible and never results in shipping a 'completed' source file with what looks like executable code enclosed inside a comment or #if/#endif. Marv Rubinstein
ok@goanna.oz.au (Richard O'keefe) (02/22/90)
In article <5372@ur-cc.UUCP>, misu_ss@uhura.cc.rochester.edu (What`s in a name?) writes: > This leads me to a question on how compilers work... > Do #defines get worked out before comments are discarded... It is quite explicit in ANSI C that comments are turned into spaces before any preprocessor directives are recognised or processed. In older C systems, particularly ones based on the "Reiser" preprocessor, this wasn't true, but portable code never could exploit it so we haven't lost anything. A consequence of the ANSI rules is that #define OPEN_COMMENT /* extern int fred[]; /* static */ int tom[2]; acts exactly like #define OPEN_COMMENT int tom[2]; If you want to do hairy things with comments and macros, M4 comes as part of the UNIX toolkit, and there's a PD implementation in C.
brianh@hpcvia.CV.HP.COM (brian_helterline) (02/23/90)
misu_ss@uhura.cc.rochester.edu (What`s in a name?) writes: > {deleted} >This leads me to a question on how compilers work... >Do #defines get worked out before comments are discarded... >I.E. if I write code thus: >#define OPEN_COMMENT "/*" >#define CLOSE_COMMENT "*/" >main() >{ >char *string[30] > string = OPEN_COMMENT; > printf("s% ", string); > string = "This is a C comment"; > printf("s% ", string); > string = CLOSE_COMMENT; > printf("s%\n", string); >} >will this produce the output: >/* This is a C comment */ >or will it simply do a newline and make string point to the return value of >printf? (likely causing a seg fault if string is ever assigned again...) >On gcc version 1.36 and cc (don't know version) running under SunOS4.0.3 >this code produces the first output. Any compilers out there that do comment >checking after filling out macros? >If this always works then this is a possible solution to the problem... >Obviously, you'll have to use string functions but is that so bad? If you >are doing something that will output C code it's going to be pretty general >in nature... There won't be a lot of cases where constant output is easiner >than variable output. > --mike On my compiler (MSC 5.1), it produced a syntax error! The line variable string should be declared as: char *string; not char *string[30] /* no semicolon */ -- Mic3hael Sullivan, Society for the Incurably Pompous -*-*-*-*- ...I know there are people in the world who do not love their fellow human beings and I *HATE* people like that! --Tom Lehrer ----------
gregory@ritcsh.cs.rit.edu (Greg Conway) (02/23/90)
In article <5372@ur-cc.UUCP> misu_ss@uhura.cc.rochester.edu (What`s in a name?) writes: >This leads me to a question on how compilers work... >Do #defines get worked out before comments are discarded... The 'traditional' implementation is that #defines's are done by the preprocessor and comments are handled by the scanner. Under such a case, the #define's are handled first. >#define OPEN_COMMENT "/*" >#define CLOSE_COMMENT "*/" [ text deleted ] > string = OPEN_COMMENT; > printf("s% ", string); [ further text deleted] According to K&R II, page 154, the behavior of this program is undefined. (The correct format conversion is %s). Assuming that the above is merely a typo, then the output you got appears to me to be correct. - Greg -- Gregory Conway @ Computer Science House, RIT "When I was young my father told me just bad guys die -- at that time just a little white lie. It was one of the first but it hurt me the most -- and the truth stung like tears in my eyes ... and even now it makes me cry." - Fish
ted@welch.jhu.edu (Ted Ying) (02/23/90)
In article <1990Feb20.165353.14212@uncecs.edu> utoddl@uncecs.edu (Todd M. Lewis) writes: > >You have quite precisely missed my point. It was even in quotes. Briefly: > 1) "comment out a section..." Use comments. > 2) "compile if x {not} defined" Use #if{n}def/#endif. >See the difference? In particular, I did not say that nested comments are >the better way to suppress the compilation of a section of code. If it's a >comment it isn't code! The notion of conditionally compiling comments is >a bit off the mark, IMHO. Comments are never compiled--nothing conditional >about that. Lexed or parsed maybe, but not compiled. > OK, Todd. I understand the difference that you are pointing out. The point you seem to be making is that comments should be restricted to non-code. However, in that case, you are usually entering text or pseudo-code or something description or important to the section of code. In that case, why would you ever want nested comments? I think that nested comments are needed only if you would like to be able to "comment" out a section of code that might have comments in it otherwise. If that is the case, then it is more appropriate to use #ifdef/#endif. I'm not saying that nested comments are useless, just that they are not necessary especially when compared with the cost for generating a nested comment parser. Ted Ying ted@welch.jhu.edu #include <std.disclaimer.h> Approximating the Taylor series: Mike Todd + Eddie Fisher + Richard Burton + John Warner + ...
gwollman@jhunix.HCF.JHU.EDU (Garrett A Wollman) (02/24/90)
... Next time you're in a weird mood, try picking out your favorite large source distribution, and change the COPTS line to: COPTS=-O -Dnotdef And see how fun things can really be... -GAWollman "This has been a private service announcement" (tag line stolen from Chris Torek) -- "All societies are based on rules to protect pregnant women and children. . . . As racial survival is the only universal morality, no other bases is possible." - Lazarus Long [RAH, _TEFL_] ---------------Hopkins doesn't *want* my opinions------------------------