// vs /*

[Kenneth Brody]

Ryan Reich wrote:
[...]

Nested comments are never ambiguous; only if you are really looking for
complication do they become ambiguous, and in that case, they're just as
ambiguous for // as for /* */. Consider:

/* A comment /* with a comment inside */
// A comment // with a comment inside

Syntactically, they're identical. The most obvious way of parsing comments
will not notice the nesting. How is it more ambiguous for the first whether
or not there's a syntax error? It's possible, even likely, that a human might
find the latter to be clearer, but who cares what humans think about how C
code is parsed? Only the compiler really cares, and the compiler is not
fooled by visual cues like which opening delimiter is closer to the closing
one, when the standard is that "the closing one" matches the _first_ opening
one, not the nearest.

Actually, neither of those is a "nested comment". The first is a
comment with "/*" within it, and the second is a comment with "//"
in it.

Unless, that is, your compiler supports nested /*...*/ comments, in
which case the first example hasn't ended the comment.

/* This is a comment /* with a nested comment */ inside of it. */

Your first objection, about commenting out large blocks, is not really valid
since to do so with /* requires only two insertions, and you can even make
those on their own new lines, which requires no interference with the existing
text at all. It's actually easier to comment out large blocks this way than
with //.

Consider this case where the compiler doesn't really "nest" /*...*/
comments. (Which is what you are assuming, given your first example.)

void foo()
{
... a bunch of code ...

/* the following code was commented out on 1-jan-2000 by xyz

foo
bar

i++; /* I added this, having not noticed that this is within
* commented-out code.
*/

bar
foo

*** end of 1-jan-2000 comment */

... some more code ...
}


[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Ryan Reich]

Ryan Reich wrote: [...]

Nested comments are never ambiguous; only if you are really looking for
complication do they become ambiguous, and in that case, they're just as
ambiguous for // as for /* */. Consider:

/* A comment /* with a comment inside */ // A comment // with a comment
inside

Syntactically, they're identical. The most obvious way of parsing comments
will not notice the nesting. How is it more ambiguous for the first
whether or not there's a syntax error? It's possible, even likely, that a
human might find the latter to be clearer, but who cares what humans think
about how C code is parsed? Only the compiler really cares, and the
compiler is not fooled by visual cues like which opening delimiter is
closer to the closing one, when the standard is that "the closing one"
matches the _first_ opening one, not the nearest.

Actually, neither of those is a "nested comment". The first is a comment
with "/*" within it, and the second is a comment with "//" in it.

Unless, that is, your compiler supports nested /*...*/ comments, in which
case the first example hasn't ended the comment.

/* This is a comment /* with a nested comment */ inside of it. */

Well, if the compiler nests comments then the first one is certainly a syntax
error, since then we have an unterminated comment. And my point is that the
second one should logically be considered a syntax error as well for the same
reason.

Interestingly, your example below breaks my theory if the compiler _doesn't_
nest comments, but if you make all the comments //, then it breaks if the
compiler _does_, since then many of the comments become unterminated. Of
course, no one ever writes a compiler that nests // comments. Perhaps that
was Keith's real point.

Your first objection, about commenting out large blocks, is not really
valid since to do so with /* requires only two insertions, and you can even
make those on their own new lines, which requires no interference with the
existing text at all. It's actually easier to comment out large blocks
this way than with //.

Consider this case where the compiler doesn't really "nest" /*...*/
comments. (Which is what you are assuming, given your first example.)

void foo() { ... a bunch of code ...

/* the following code was commented out on 1-jan-2000 by xyz

foo bar

i++; /* I added this, having not noticed that this is within
* commented-out code.
*/

bar
foo

*** end of 1-jan-2000 comment */

... some more code ...
}


[...]

This, however, I was wrong about.

 

[Bill Pursell]

/* This is a comment /* with a nested comment */ inside of it. */

// And just for completeness // this is nested
while this line is part of the outer comment!!

 

[Keith Thompson]

If you used it as an argument that Oreos are available everywhere, yes,
that would be a valid counterpoint.

Please don't feed the troll.

 

[Keith Thompson]

Nested comments are never ambiguous; only if you are really looking for
complication do they become ambiguous, and in that case, they're just as
ambiguous for // as for /* */.

Of course there's no ambiguity as far as the compiler is concerned,
since the language has explicit rules that resolve any potential
ambiguity. In the case of /* */ comments, the rule is that a /*
sequence within a /* */ comment is ignored.

Of course, the language *could* have specified that nested comments
are significant, for example:

/* In a comment /* nested comment */ still in the outer comment */

But since comments are intended for the reader (the compiler is merely
responsible for ignoring them properly), they should be as easy for
humans to read as possible.

[...]

Your first objection, about commenting out large blocks, is not
really valid since to do so with /* requires only two insertions,
and you can even make those on their own new lines, which requires
no interference with the existing text at all. It's actually easier
to comment out large blocks this way than with //.

Not really. If the block being commented out already has comments,
you can't just commented out out by adding another layer of /* ... */:

/* Commenting out the following two statements

statement1; /* Here's a comment */
statement2; /* Oops, statement2 isn't commented out! */

end of block being commented out */

You're likely to get a syntax error at the end (though I'm sure cases
could be constructed where you wouldn't).

Of course, the best way to "comment out" blocks of code in C is to use
"#if 0" ... "#endif". This still has the problem that it's not
obvious if you're looking at the middle of the block, but at least it
nests properly.

To uncomment is another story, since text is line-based but /* */ is
non-local, but in practice you have either syntax highlighting, so
the editor knows this non-local information, or you follow a common
style and put a * at the beginning of each commented line, in which
case for the purposes of automation there is no difference between
/* */ and //.

Actually, there is. Adding either "// " or "* " to the beginning of
each of a range of lines is typically a single operation. In the
latter case, adding the "/*" at the top and the "*/" at the bottom is
another separate operation (unless you define a macro to do the whole
thing, which is admittedly a reasonable approach). But again, you'll
run into problems with nested comments.

One of the major reasons I like end-of-line comments is that they're
localized. It's obvious what is and is not commented out on a given
line without having to look up or down the file for a comment
delimiter.

[...]

Of course not. For example, you wisely chose not to name the
"decent editor" with which one would be commenting out code.

Indeed.

:wq

 

[Keith Thompson]

Actually, neither of those is a "nested comment". The first is a
comment with "/*" within it, and the second is a comment with "//"
in it.

Unless, that is, your compiler supports nested /*...*/ comments, in
which case the first example hasn't ended the comment.

/* This is a comment /* with a nested comment */ inside of it. */

If your compiler supports nested /* ... */ comments, it's not a
conforming C compiler.

 

[Richard Heathfield]

Keith Thompson said:

If your compiler supports nested /* ... */ comments, it's not a
conforming C compiler.

I disagree. Conforming compilers are allowed to provide extensions, provided
a strictly conforming program doesn't notice those extensions. Since a
strictly conforming program won't have any nested comments in it, it won't
notice that they're allowed, so there's no conformance issue.

 

[Bill Pursell]

Actually, there is. Adding either "// " or "* " to the beginning of
each of a range of lines is typically a single operation. In the
latter case, adding the "/*" at the top and the "*/" at the bottom is
another separate operation (unless you define a macro to do the whole
thing, which is admittedly a reasonable approach). But again, you'll
run into problems with nested comments.

One of the major reasons I like end-of-line comments is that they're
localized. It's obvious what is and is not commented out on a given
line without having to look up or down the file for a comment
delimiter.

I'll agree with Keith--
uncommenting is much easier with end-of-line comments.
Consider:
# code_that_is_commented_out
# second_line_of_commented_code
## comment in the commented out block
# another_line_of_commented_code

Removing one layer of the comment symbol exposes
the 3 lines of code and leaves the original comment
as a comment.

But for some reason I have a visceral reaction to // in
C code. I suppose I'm being completely irrational, but
it just really irks me.

 

[Ben Pfaff]

Since a strictly conforming program won't have any nested
comments in it, it won't notice that they're allowed, so
there's no conformance issue.

Strictly conforming programs can be broken by a nested comment
extension, e.g.

/*#include <stdio.h> /* Not needed, why was this here? */

 

[Richard Heathfield]

Bill Pursell said:

I'll agree with Keith--
uncommenting is much easier with end-of-line comments.
Consider:
# code_that_is_commented_out
# second_line_of_commented_code
## comment in the commented out block
# another_line_of_commented_code

Removing one layer of the comment symbol exposes
the 3 lines of code and leaves the original comment
as a comment.

Comments should be used to comment code, not to disable it.

If you want temporarily to disable a bunch of code, this is very easy to do
without comments:

#if 0
foo(); /* widgetify the grommets */
bar(); /* fudge the custard grinder */
#endif

And you can trivially re-enable the code by changing a single character.

But for some reason I have a visceral reaction to // in
C code. I suppose I'm being completely irrational, but
it just really irks me.

I have three principal objections to them. Firstly, it is all too easy, on
Win32 platforms, to do this:

foo(); // widgetify the grommets, default directory is c:\temp\
bar(); // why oh WHY isn't this being called?

Secondly, I've already mentioned elsethread that switching them on also
switches off ANSI conformance in my implementation.

Thirdly, they encourage the appalling practice of "commenting out" code
instead of disabling it properly.

 

[Guest]

Strictly conforming programs can be broken by a nested comment
extension, e.g.

/*#include <stdio.h> /* Not needed, why was this here? */

I think the logic was that */ can't occur outside of a comment in a
s.c. program, so if the compiler encountered */ outside of a comment,
it could re-preprocess the file, this time while supporting nested
comments, so I think an example like this would explain it better:

int main(void) {
return 0 /* /* */ *// 0;
0;
}

 

[Richard Heathfield]

Ben Pfaff said:

Strictly conforming programs can be broken by a nested comment
extension, e.g.

/*#include <stdio.h> /* Not needed, why was this here? */

Fair comment... er, I mean, fair point. But if I can just clutch at a straw
as I go hurtling over the cliff, I'd like to point out that your example's
comment isn't actually a nested comment, since it has insufficiently many
closing */s.

 

[Andrew Poelstra]

I think the logic was that */ can't occur outside of a comment in a
s.c. program, so if the compiler encountered */ outside of a comment,
it could re-preprocess the file, this time while supporting nested
comments, so I think an example like this would explain it better:

int main(void) {
return 0 /* /* */ *// 0;
0;
}

Wow, that made my head hurt. I couldn't figure out what *// could
mean. Is it closing or opening a comment?

Compiler supports nesting:
Compiler supports //:
return 0 / 0; /* Dividing by 0 is undefined. */
return 0 0; /* This might also be possible. */
Compiler doesn't support //:
return 0 / 0; /* Dividing by 0 is undefined. */
Compiler doesn't support nesting:
Compiler supports //:
return 0 * 0;
Compiler doesn't support //:
return 0 *// 0; /* Syntax error */

 

[Keith Thompson]

Comments should be used to comment code, not to disable it.

If you want temporarily to disable a bunch of code, this is very easy to do
without comments:

#if 0
foo(); /* widgetify the grommets */
bar(); /* fudge the custard grinder */
#endif

And you can trivially re-enable the code by changing a single character.

I agree completely in the context of C as it's currently defined
(which is, of course, the topic of this newsgroup).

But if you look at programming languages in general, most of them
don't have C's "#if ... "#endif" construct. In such languages, if
they have end-of-line comments (delimited by, say, "//", or "#", or
"--"), then commenting out blocks of code is perfectly reasonable.

And if C had retained BCPL's "//" end-of-line comments, rather than
replacing them with "/* ... */" (and re-adding "//" many years later),
then I would argue that commenting out blocks of C code would be
equally reasonable.

The trailing '\' problem is significant, of course, but as long as I'm
changing history I'll get rid of that problem as well ... somehow.

[...]

I have three principal objections to them. Firstly, it is all too easy, on
Win32 platforms, to do this:

foo(); // widgetify the grommets, default directory is c:\temp\
bar(); // why oh WHY isn't this being called?

That's something I hadn't thought of before this thread. I would
*hope* that a compiler would issue a warning for this kind of thing --
and for a '\' followed by whitespace, which *doens't* cause line
splicing.

Secondly, I've already mentioned elsethread that switching them on also
switches off ANSI conformance in my implementation.

Good point.

Thirdly, they encourage the appalling practice of "commenting out" code
instead of disabling it properly.

I disagree on this point, but of course it's a matter of taste.

 

[Mark McIntyre]

Conforming compilers are allowed to provide extensions, provided
a strictly conforming program doesn't notice those extensions.

Hmm. This argument can be applied to void main() and treating pointers
as ints. Are you sure you want to use it?

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Andrew Poelstra]

Hmm. This argument can be applied to void main() and treating pointers
as ints. Are you sure you want to use it?

Why not? Both of those may be allowed, but they're no more topical
to clc than nested comments are. Nor is it guaranteed that they are
any more or less portable.

 

[Richard Heathfield]

Keith Thompson said:

[...]

#endif

And you can trivially re-enable the code by changing a single character.

I agree completely in the context of C as it's currently defined
Fabulous.

(which is, of course, the topic of this newsgroup).
Right.

But if you look at programming languages in general,

....then you stray from the topic!

Seriously, my comments(!) are relevant only to C and its close relatives.
Whether they apply to programming languages in general is impossible to
answer. Such matters of style are heavily syntax-dependent. For example, if
C didn't have line-splicing, a third of my objection would fall away. If C
didn't have a preprocessor, bang would go another third. And if C had
supported // comments in C89, the remainder of my case would collapse in a
sad little heap on the floor.

But it does, and it does, and it didn't, so it doesn't, and it doesn't, and
it doesn't. In that order.

 

[Richard Heathfield]

Mark McIntyre said:

Hmm. This argument can be applied to void main() and treating pointers
as ints. Are you sure you want to use it?

Sure. Any compiler is allowed to accept void main as an extension. We always
knew that. That doesn't mean that void main programs are correct in the
comp.lang.c sense (because no compiler is /required/ to accept void main,
and some implementations do indeed reject it).

 

[Kenneth Brody]

// And just for completeness // this is nested
while this line is part of the outer comment!!

It depends. With "/*...*/" comments, the closing "*/" is consumed
as part of the comment, whereas with "//" comments the closing
newline is not part of the comment, and remains. One could argue
that the newline closes both "//" comments.

And, just to make things "interesting", what about nesting mixed
comment styles?

Like this:

i++; // this is a comment /* what about this?
"is this a comment, or real code?"
is this a symtax error? */

Or:

i++; /* This is a comment // some more */

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Kenneth Brody]

Richard Heathfield wrote:
[...]

I have three principal objections to them. Firstly, it is all too easy, on
Win32 platforms, to do this:

foo(); // widgetify the grommets, default directory is c:\temp\
bar(); // why oh WHY isn't this being called?

[...]

Eww... I hadn't realized that would continue the comment onto the
second line. (Not that I'd ever use such a construct, mind you.)
But, you are correct, and the call to bar() disappears inside the
comment. (At least with MSVC6. Is this guaranteed by the Standard?)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>