markhall@pyramid.pyramid.com (Mark Hall) (01/20/88)
I have a brief observation about comment operators, which applies
to C as well as other languages. Rather than suggest that it be
incorporated into ANSI C, I would only like to hear your views, and
either (a) build up some ground swell of support, or (b) discover why
it is a bad idea.
If it has been discussed before, please refer me to the article numbers.
I would like to give two short arguments for having nested comments.
1. it is often convenient to `comment-out' code that already
has comments in it, either because you don't want to RUN the code,
or because you don't want to COMPILE the code. If you don't want to
run the code, you can encircling it like:
if (FALSE) {
. . . offending code with comments . . .
}
but this means that the `offending code' must be syntactically
correct, or the compiler will not produce an executable (even
though the code cannot be executed), so we cannot use this method
when we don't want to compile the offending code. (Note that having
nested comments here would aid appreciably in performing the
`binary bug hunt'.)
2. using nested comments, you are much less likely to suffer from
mistakes of the form:
a=b; /* <-- comment starts here
c=d; /* comment ends here --> */
The compiler would, in all likelyhood, run til EOF looking for the
matching comment and, since it knows which begin-comment it is
trying to match, could point back to the offending comment above
and report ``no close comment found matching this fellow''.
Please send useful comments to:
{seismo|sun|decwrl|hplabs|lll-lcc|ut-sally|amdahl}!pyramid!markhall
flames to:
/dev/null
*******
Mark Hall -
#include <std_disclaimer.h>jbs@eddie.MIT.EDU (Jeff Siegal) (01/20/88)
In article <13423@pyramid.pyramid.com> markhall@pyramid.UUCP (Mark Hall) writes: > 1. it is often convenient to `comment-out' code that already > has comments in it, either because you don't want to RUN the code, > or because you don't want to COMPILE the code. Try this: #ifdef COMPILE_BROKEN_CODE ... broken code ... #endif Jeff Siegal
joemac@apple.UUCP (Joe MacDougald) (01/20/88)
Rather then using nested comments, why not use: #ifdef 0 int a = 1; /* COMMENT */ int b = a; /* COMMENT */ #endif | UUCP {decwrl, inhp4, hplabs, sun}!apple!joemac | | Internet joemac@apple.com | | | | The standard disclaimer applies: "I do not speak for Apple Computer, Inc." |
nevin1@ihlpf.ATT.COM (00704A-Liber) (01/21/88)
In article <13423@pyramid.pyramid.com> markhall@pyramid.UUCP (Mark Hall) writes: .I have a brief observation about comment operators, which applies .to C as well as other languages. Rather than suggest that it be .incorporated into ANSI C, I would only like to hear your views, and .either (a) build up some ground swell of support, or (b) discover why .it is a bad idea. . .I would like to give two short arguments for having nested comments. . . 1. it is often convenient to `comment-out' code that already . has comments in it, either because you don't want to RUN the code, . or because you don't want to COMPILE the code. If you don't want to . run the code, you can encircling it like: . if (FALSE) { . . . . offending code with comments . . . . } . but this means that the `offending code' must be syntactically . correct, or the compiler will not produce an executable (even . though the code cannot be executed), so we cannot use this method . when we don't want to compile the offending code. (Note that having . nested comments here would aid appreciably in performing the . `binary bug hunt'.) If you do not want to compile offending code, it would be better to use macros than to comment out the code; i.e., if (FALSE) { #ifndef THIS_IS_CODE_I_DO_NOT_WANT_TO_COMPILE_RIGHT_NOW /*No flames about the obviously long identifier :-)*/ . . . offending code with anything you want . . . #endif } . . 2. using nested comments, you are much less likely to suffer from . mistakes of the form: . a=b; /* <-- comment starts here . c=d; /* comment ends here --> */ . The compiler would, in all likelyhood, run til EOF looking for the . matching comment and, since it knows which begin-comment it is . trying to match, could point back to the offending comment above . and report ``no close comment found matching this fellow''. Yes, but you may introduce errors that LISP programmers sometimes suffer from (by having too many parentheses): If there are too many nested comments, it may become very hard to determine how many end comment markers should be put in and where they should go. The worst problem I can see for nesting comments in C is that it might break existing code. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
tanner@ki4pv.uucp (Dr. T. Andrews) (01/22/88)
In article <13423@pyramid.pyramid.com>, markhall@pyramid.pyramid.com (Mark Hall) writes:
) I would like to give two short arguments for having nested comments.
From "defs.h", (C) 1986 Rick Adams, comes this amusing section of a
configuration file:
#define INTERNET /* Internet mail works locally */
#define MYDOMAIN ".uucp" /* Local domain */
/* #define CHEAP /* don't chown files to news */
/* #define OLD /* Add extra headers for old neighbors */
/* #define UNAME /* If uname call returns your nodename */
/* #define GHNAME /* If gethostname call is available. */
--
{allegra clyde!codas decvax!ucf-cs ihnp4!codas killer}!ki4pv!tannermsb@sq.uucp (Mark Brader) (01/22/88)
> 2. using nested comments, you are much less likely to suffer from > mistakes of the form: > a=b; /* <-- comment starts here > c=d; /* comment ends here --> */ This is easily covered by a compiler warning of the form Warning - /* found within comment - check for missing */ I have used either a B or C compiler that did this, but I don't remember where. Probably B at Waterloo. In my opinion "commenting out" seriously detracts from readability and should be avoided like the plague. There are other ways to preserve old versions of the code (SCCS, RCS, mv). If I really must do it temporarily, I use #if 0 or #ifdef NEVER. (Not #ifndef, of course. I recently got burned by not noticing that someone had coded #ifndef NEVER ... #else in a program I was modifying.) Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com We can design a system that's proof against accident and stupidity; but we CAN'T design one that's proof against deliberate malice. -- a spaceship designer in Arthur C. Clarke's "2001: A Space Odyssey"
ericb@athertn.Atherton.COM (Eric Black) (01/22/88)
In article <7224@apple.UUCP> joemac@apple.UUCP (Joe MacDougald) writes: >Rather then using nested comments, why not use: > >#ifdef 0 > >int a = 1; /* COMMENT */ >int b = a; /* COMMENT */ > >#endif Because "0" is not a legal preprocessor symbol, and some compilers/preprocessors will complain (e.g. VMS C). Instead, use: #if 0 ... #endif or: #ifdef notdef ... #endif Compiling code containing the latter construct with a -Dnotdef is kind of like certain FORTRAN (and other) compilers that share constants and pass parameters by reference; the laws of the universe can change, and 3 can be equal to 2... -- Eric Black "Garbage in, Gospel out" UUCP: {sun!sunncal,hpda}!athertn!ericb Domainist: ericb@Atherton.COM
ok@quintus.UUCP (Richard A. O'Keefe) (01/23/88)
If you have a pretty-printer (in 4BSD systems, see vgrind(1)) you want commented-out code to be formatted AS CODE, not as comments. I have a utility which displays files on a terminal with comments highlighted. I want unused code to look like code (I might want keywords underlined, for example). #if 0/#endif is exactly right for "commenting out". (It nests...) If you have a decent editor it is trivially easy to write a command which "comments out" a region even without nestable comments. The trick is this: insert */ at the end of the region while not at the beginning of the region move back one character if character is '/' replace it by " / " insert /* (we are now at the beginning). Any "/*xxx*/" comment inside will now be broken up as " / *xxx* / ". Inverting the operation is just as easy: replace each ' / ' in the region by '/'.
gnu@hoptoad.uucp (John Gilmore) (01/25/88)
jbs@eddie.MIT.EDU (Jeff Siegal) wrote: > #ifdef COMPILE_BROKEN_CODE > > ... broken code ... > > #endif Unfortunately, ANSI C makes this less likely to work. The old Unix preprocessor ignored ' and " inside #ifdef's, so you really could #ifdef out just about anything you wanted, other than unterminated /* comments. But you might argue that it errs on stuff like this: #ifdef FOO printf("\ #endif FOO\ \n"); since it terminates the #ifdef at the #endif. Indeed, ANSI C says that the #endif does NOT terminate the #ifdef. The problem is that old code assumed it could put ' and " in #ifdef 0's; in particular it gets used for commentary that includes "can't" or "didn't" or other uses of unmatched single quotes; and the C preprocessor is also used on assembler sources, which use ' singly rather than in pairs (at least in the Vax assembler). So you'd better be sure that at least the quotes line up in your "broken code" before you #if 0 or #ifdef NOTDEF it away... -- {pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com "Watch me change my world..." -- Liquid Theatre
tneff@bfmny0.UU.NET (Tom Neff) (10/20/89)
In particular, a nested-comments compiler might louse up the common form of optional configuration defines: /* #define SYSV /* set this for System V */ #define BSD4_3 /* set this for BSD 4.3 */ /* #define VMS /* set this for VMS */ etcetera. It was a species of cuteness to capitalize on such comment strangeness in the first place IMHO but now we're in bed with it. -- "NASA Announces New Deck Chair Arrangement For \_/ Tom Neff Space Station Titanic" -- press release 89-7654 \_/ tneff@bfmny0.UU.NET
flaps@dgp.toronto.edu (Alan J Rosenthal) (10/24/89)
>>>> Such compilers are *broken*, at least as C compilers. >>> >>>I don't get it. Are you saying that a C compiler that allows the option >>>of nested comments is *broken*? I believe Turbo C has a nested comments >>>option. >> >>Yes, please re-read my reply. austin@bucsf.bu.edu (Austin Ziegler) writes: >As a rule, I do not use nested comments in C, but I *have* found the need to >comment it out because I am not fully acquainted with all of the features of >the preprocessor commands. Aha!!! Finally we see what is going on. Some people who do not know C very well are being told that nested comments are good. Well, let me set them right on this score: -> nested comments are bad in C. Not only bad, in fact non-existant. Now Turbo C seems to pander to pascal programmers, and provides an option to enable nested comments (only for debugging!). They have to document this option, of course. So, they have chosen to document this option rather than to document correct use of "#if 0" ... "#endif". -> This is bad. ajr -- Vs encr vf n xvaq bs frk, gura n chapu va gur zbhgu vf n xvaq bs gnyxvat.
ronald@ibmpcug.co.uk (Ronald Khoo) (10/26/89)
In article <1989Oct25.090616.19276@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes: > I've known PL/1 programmers to avoid commenting > their code because (since PL/1 comments don't nest) it would inhibit this > handy testing trick. Well, I don't know PL/1, so maybe it's a language/compilation system deficiency, but it sounds more like incompetence to me... what's wrong with stubs and new code in a fresh source file ? Anyway, back to C, you have #if 0 (#ifdef notdef to you ancient lot :-) to fall back on... Any followups are probably gonna be religious in nature, so I'm taking this discussion to alt.religion.computers, or maybe it'll die (please!) ? -- Ronald.Khoo@ibmpcug.CO.UK (The IBM PC User Group, PO Box 360, Harrow HA1 4LQ) Path: ...mc$CPU!ukc!ibmpcug!ronald Phone: +44-1-863 1191 Fax: +44-1-863 6095 $Header: /users/ronald/.signature,v 1.2 89/10/16 17:14:28 ronald Exp $ :-)
martin@mwtech.UUCP (Martin Weitzel) (02/21/90)
To early for a summary? May be, but I don't hope so.
From time to time between C programmers there starts a war between
two groups: One favours nested comments (I'll call them the 'NESTERs')
and the other doesn't like this at all (I'll call them 'PURISTs').
Though I'm using C for such a long time, that I myself am a little
biased and feel a more as a PURIST, I'll try to be fair to the NESTERs
in this summary.
I think, the discussion centers around the following issues:
1) Give the programmer the possibility to 'comment out' some
code, especially during phases of debugging and testing.
2) Avoid the possibility of introducing 'subtle bugs'.
3) Care about efficiency of the Compiler when parsing
(or here better "lexing") some source file.
4) Problems with rules for exact semantics of nested of comments.
Let's look who is better armed for the battle. (I'll not say, that this
group will win, as the 'Holy Scriptures'(%) allready have spoken truth.)
(%: Hi Henry, I hope you have no exclusive rights on this phrase :-))
IMHO (1) is the true reason why many NESTERs become so angry and
furious, for C invalidates one of their debugging techniques: Commenting
out cumbersome parts of the source. Of course, the PURISTs say: You
should not want to do this, rather use #if-#endif for that purpose.
To be fair, having #if-#endif would not speak *against* allowing
nested comments, so it's no real argument *for* the PURISTs, but at
least the NESTERs should answer the question: "Why do you still want
to use comments for this purpose, if you can do it in another way
equally well?".
If a programmer shifts from any-language-with-nested-comments to C,
he or she has to change a lot of habbits. Why not simply change the
way you use to 'comment out' parts of your source? You even gain
some advantage: Now you may switch "from outside" (with cc -D ...)
between your versions, esp. if you use #if a little systematically.
On the next round (2) I think, the NESTERs have a little more
weight on their side, because the subtle bugs they have shown
(mistakenly typing * / instead of */) seem a little more probable
and far harder to detect.
A PURIST (as me) must have a tool available, to check for this
(eg I have a pretty printer for C that prefixes every line in an
open comment with an asterix), but I confess, this is a workaround
and it would not guarantee, that I detect such bugs immediatly.
Of course, a compiler could choose to issue a warning, if a '/*'
is detected within a comment - but if the compiler cares at all,
why not make nested comments completly legal?
Let's go on to (3). I suppose a Compiler has to do a lot of work
anyway. If a comment is encountered (nesting allowed or not)
it must be read through and the sequence '/*' within a comment
seems far less probable than all the other characters. So, does
the time for counting levels of nesting really count? Come on all
you PURISTs (and me too): Don't beat onto the NESTERs with the
argument of "lost efficiency", this beats back onto you!
At this time it looks good for the NESTERs, but we still have (4).
I think Raymond Chen (raymond@math.berkeley.edu), has made a very
valid point in his article, from which the following is an excerpt:
Please present a coherent rule for nested comments for which the
following lines of code produce "expected" results:
int openquote = 34; /* " */ int closequote = 34; /* Also " */
int quote = 34; /* for a good time, type printf("*/ %c",quote) */
/* int doublequote = 34; /* " */ */ /* don't need this one: '"' */
/* printf("*/ is the close-comment token\n");
printf("/* is the \"open-comment\" token\n"); */
Maybe you are not interested in using nested comments in such
"pathological" cases, but hey, NESTERs, don't you think sometimes
the ANSI-Standard Document for C is far too complicated to be
understood by any mortal (except Chris and Henry and a few others)?
Isn't it nice to have the simple rule: "A comment starts with
slash-asterix and ends with asterix-slash" POINT.
Would you really like to read: "A comment starts with slash-asterix.
Any further slash-asterix will increment a counter starting from
zero and any asterix-slash will decrement the counter. If the counter
eventually drops below zero, the comment is finished." Wouldn't you
then moan with regard to the last two lines in the above example,
that you could *not* simply comment out the code and ask: Why can't
C not look for double quotes within comments and *stop* delimiter
counting in this situation?
Again, the examples above may never be of any concern to you, but
some C Reference *has* to specify the language to the degree, that
the same source (hopefully) compiles to a program with the same
behaviour using different compilers. (Or at least it must point
out the "grey areas".) Again I ask you: Would you like this really
more than the current most simple rule?
To draw the bottom line I would propose: A compiler may well warn
about the sequence slash-asterix *within* a comment, we should use
#if-#endif for the purpose of 'commenting out' some part of the
source, but we should not want to have nested comments supported.
This should satisfy NESTERs and PURISTs.
Excuse me for this long posting, I've written it because
I hope it might keep some other traffic away from the net.
--
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
--
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83henry@utzoo.uucp (Henry Spencer) (02/23/90)
In article <648@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >... the 'Holy Scriptures'(%) allready have spoken truth.) > >(%: Hi Henry, I hope you have no exclusive rights on this phrase :-)) Of course not. Just send in the royalty check promptly after each use of it, and no dire harm will befall you. :-) >To draw the bottom line I would propose: A compiler may well warn >about the sequence slash-asterix *within* a comment... The Holy Scriptures (Oct 88 draft) in fact mention this as a common warning. -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
ted@welch.jhu.edu (Ted Ying) (02/24/90)
Nice summary! I think that you tried to be fair to both sides of the debate, however, I disagree with you on certain points (as to the weight of arguments). Then again, I am a purist, according to your definition so it falls to logic to assume that I would favor that side: In article <648@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: > >1) Give the programmer the possibility to 'comment out' some > code, especially during phases of debugging and testing. >2) Avoid the possibility of introducing 'subtle bugs'. >3) Care about efficiency of the Compiler when parsing > (or here better "lexing") some source file. >4) Problems with rules for exact semantics of nested of comments. > > [...arguments for/against (1)...] > >On the next round (2) I think, the NESTERs have a little more >weight on their side, because the subtle bugs they have shown >(mistakenly typing * / instead of */) seem a little more probable >and far harder to detect. > Here, I disagree. The subtle bugs that affect non-nested comments are still as evident in nested comments. Additionally, there are other subtle problems that come in with nested comments that are not there for non-nested comments. For example, with nested comments you have to add in a check for strings (double quotes) before you increment your level-counter for comments. If you don't take into account, or don't take into account properly, then you have another subtle error. THe problem of '* /' vs. '*/' should have the same effect on the compilation of the program whether or not you are nesting comments. Thus I find that nesting doesn't solve any problems, and could create more. > [...arguments for/against (3) and (4)...] > As I said, I find that it was a nice summary. I thought the detail in arguments around issue (4) were nicely written and agree with them. Ted Ying ted@welch.jhu.edu #include <std.disclaimer.h> Approximating the Taylor series: Mike Todd + Eddie Fisher + Richard Burton + John Warner + ...
ado@elsie.UUCP (Arthur David Olson) (02/24/90)
> > To draw the bottom line I would propose: A compiler may well warn > > about the sequence slash-asterix *within* a comment... > > The Holy Scriptures (Oct 88 draft) in fact mention this as a common warning. The mention occurs in the Apocrypha. . .er, in an Appendix. The Standard itself says "The contents of a comment are examined *only* to identify multibyte characters and to find the characters */ that terminate it" (emphasis added). Since Standard-conforming compilers can only look for the terminating */, they cannot hunt for /*'s, at least by my reading. -- Arthur David Olson ado@alw.nih.gov ADO is a trademark of Ampex.
henry@utzoo.uucp (Henry Spencer) (02/25/90)
In article <90136@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >> > To draw the bottom line I would propose: A compiler may well warn >> > about the sequence slash-asterix *within* a comment... >> >> The Holy Scriptures (Oct 88 draft) in fact mention this as a common warning. > >The mention occurs in the Apocrypha. . .er, in an Appendix. The Standard >itself says "The contents of a comment are examined *only* to identify >multibyte characters and to find the characters */ that terminate it" >(emphasis added). Since Standard-conforming compilers can only look for >the terminating */, they cannot hunt for /*'s, at least by my reading. By this reasoning, compilers would be forbidden to (e.g.) produce source listings. The issue comes under the "as if" rule: so long as the compiler handles multibyte characters and */ properly, and does not reject the program or generate different code because of something in a comment, it can do anything it wants with comment text. Warning messages, listings, etc. are entirely outside the Standard's jurisdiction. -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu