nesting coments

[Mantorok Redgormor]

I have a question for the sages here.

the comp.lang.c faq says:

20.20: Why don't C comments nest? Are they legal inside quoted
strings?

A: C comments don't nest because PL/I's comments don't either. The
character sequences /* and */ are not special within double-
quoted strings.


so what is the reason for the latter mentioned language
to not nest comments? Was it purely a design choice?
i.e., it wasn't that it was difficult to implement
it was just horribly ugly?

I, myself, wouldn't want nested comments because
it opens doors for allowing unnecessary cluttering
and conflation. But I'm curious as to the actual reason
behind disallowing it.

 

[Leor Zolman]

I have a question for the sages here.

the comp.lang.c faq says:

20.20: Why don't C comments nest? Are they legal inside quoted
strings?

A: C comments don't nest because PL/I's comments don't either. The
character sequences /* and */ are not special within double-
quoted strings.


so what is the reason for the latter mentioned language
to not nest comments? Was it purely a design choice?
i.e., it wasn't that it was difficult to implement
it was just horribly ugly?

I, myself, wouldn't want nested comments because
it opens doors for allowing unnecessary cluttering
and conflation. But I'm curious as to the actual reason
behind disallowing it.

To quickly nip "runaway" comments in the bud? Personally, I always wanted
to be able to use nested comments, so I believe I had BDS C support them
(it is amazing how many specific features of that compiler I cannot
remember precisely). But at the same time (or at least soon after folks
began complaining), I included a diagnostic pointing to the /start/ of the
outer-level runaway comment if the compiler reached EOF and was still
within a comment. Without that diagnostic ability, the "feature" would have
been a nightmare...
-leor

 

[CBFalconer]

.... snip ...

I, myself, wouldn't want nested comments because it opens doors
for allowing unnecessary cluttering and conflation. But I'm
curious as to the actual reason behind disallowing it.

Probably because back in pre-historic times it was much easier to
parse. We read the sequence "/*", discard it, and read source
until the sequence "*/" appears, returning a single blank. No
need to count things, save things, whatever.

It remains easier to parse.

 

[Martin Dickopp]

Personally, I always wanted to be able to use nested comments,

Why? What would you possibly want to say in a comment (i.e. in an
explanatory text) that requires nested comments?

The only reason I can see why one would nest comments is to temporarily
"comment out" code sections. For that, I prefer #if 0 ... #endif, which
does nest.

Martin

 

[Leor Zolman]

Why? What would you possibly want to say in a comment (i.e. in an
explanatory text) that requires nested comments?

The only reason I can see why one would nest comments is to temporarily
"comment out" code sections. For that, I prefer #if 0 ... #endif, which
does nest.

Well, /I/ prefer commenting out code sections with comments while
debugging...less typing, more intuitive to me. Your mileage obviously
varies. Note that I don't prefer it /enough/ to go throwing compiler
switches now in order to have it supported. I just use C++ comments
everywhere...so I can temporarily comment out at least one non-nested
section when necessary using C comments.

I grumble when code I've copied-and-pasted from a newsgroup post has C
comments and I need to comment out a section ;-)
-leor

 

[Leor Zolman]

Probably because back in pre-historic times it was much easier to
parse. We read the sequence "/*", discard it, and read source
until the sequence "*/" appears, returning a single blank. No
need to count things, save things, whatever.

It remains easier to parse.

But not by much, and the resources saved on contemporary systems would have
to be described as infinitesimal.

As I recall, when that BDS C user complained about the "unexpected EOF"
message early versions of the compiler gave as a result of runaway
comments, it took me all of an hour or so to add the smarter diagnostic
capability (and most of that was waiting for the assembler to churn through
several debug cycles.) Afterwards I felt like an idiot for not having
thought of doing that in the first place. I must not have written any test
programs with runaway comments.
-leor

 

[CBFalconer]

.... snip ...

I grumble when code I've copied-and-pasted from a newsgroup post
has C comments and I need to comment out a section ;-)

I grumble AND BITCH when such code has C++ comments, illegal under
C89, and even worse, wrapped during posting.

 

[Leor Zolman]

I grumble AND BITCH when such code has C++ comments, illegal under
C89, and even worse, wrapped during posting.

I /have/ been trying to remember to use only C comments here in clc, in
deference to folks having (or choosing) to use compilers (or settings) that
don't support the C++-style comments. And yes, the wrapping /is/ a total
pain in the ass, I must agree.

But this does still seem to be a case of irresistable force meets immovable
object...
-leor

 

[Leor Zolman]

I grumble AND BITCH when such code has C++ comments, illegal under
C89, and even worse, wrapped during posting.

BTW, I cracked up over your Mr. Ed sig on that message...and finally
realized the value of that funky "-- " sig separator as I tried to reply
and include the quote in my response ;-)
-leor

 

[Peter Pichler]

I have a question for the sages here.

the comp.lang.c faq says:

20.20: Why don't C comments nest? Are they legal inside quoted
strings?

Just an observation: this is the first time I see this "frequently asked
question" actually asked.

Peter

 

[Leor Zolman]

Just an observation: this is the first time I see this "frequently asked
question" actually asked.

So that implies either that it isn't really an FA'd Q, or that we have new
posters quivering in their boots about posting Q's from the FAQ and
everyone has read the answer there already... (NOT!)
-leor

 

[Joe Wright]

Leor Zolman wrote:

[ snip all ]

What would be the harm in a compiler allowing and supporting nested
comments? Even though Standard C doesn't support it, is a conforming
compiler required to diagnose it as an error?

But now that I think about it, nesting comments doesn't make sense. In
fact we probably use the term 'comment' badly and abuse its intent. What
do we think when we 'comment out' parts of our program? We are not
making a comment, we are trying to hide the stuff from the compiler.

At least two methods for hiding code come immediately to mind.

#if 0
...hidden code..
#endif

and

if (0) {
..hidden code..
}

Both methods can be nested.

Note that the ..hidden code.. is still parsed by the compiler. Syntax
and other errors are checked and reported. You can't put free-form text
in there the way you do with comments.

 

[Peter Pichler]

#if 0
..hidden code..
#endif

Note that the ..hidden code.. is still parsed by the compiler. Syntax
and other errors are checked and reported. You can't put free-form text
in there the way you do with comments.

A minor correction: it is parsed by the /preprocessor/. Syntax and other
errors are /not/ checked and reported, provided they form valid
preprocessor tokens. Your last sentence is true, though.

Peter

 

[Leor Zolman]

Leor Zolman wrote:

[ snip all ]

What would be the harm in a compiler allowing and supporting nested
comments? Even though Standard C doesn't support it, is a conforming
compiler required to diagnose it as an error?

But now that I think about it, nesting comments doesn't make sense.

Not for code you wish to release, of course not.

In
fact we probably use the term 'comment' badly and abuse its intent. What
do we think when we 'comment out' parts of our program? We are not
making a comment, we are trying to hide the stuff from the compiler.

Precisely. In my case, for debugging purposes.

At least two methods for hiding code come immediately to mind.

#if 0
..hidden code..
#endif

and

if (0) {
..hidden code..
}

Both methods can be nested.

And both are a pain compared to simply commenting out sections of code;
say, if you're trying to play with two alternate forms of a construct, and
don't wish to have to go "formalize" the process with a preprocessor
symbol, etc. etc. ad nauseam.

Note that the ..hidden code.. is still parsed by the compiler.

In the scenarios I'm talking about, that's /not/ what I want!

Syntax
and other errors are checked and reported. You can't put free-form text
in there the way you do with comments.

With nested comments, I can have any ole' broken, half-baked code in there,
and that's exactly what I /do/ want to be able to have in there.
-leor

 

[Eric Sosman]

Leor Zolman wrote:

[ snip all ]

What would be the harm in a compiler allowing and supporting nested
comments? Even though Standard C doesn't support it, is a conforming
compiler required to diagnose it as an error?

The compiler is not required to issue a diagnostic when
`/*' appears inside a comment, if that's what you mean. On
the other hand, the compiler must diagnose `/* /* */ */'
because the comment ends at the first `*/', and the second
`*/' is a syntax error.

With C99, of course, nested comments are perfectly legal:

/* This is an outer comment ...
// ... containing a nested comment ...
... and then the outer comment continues */

However, the use of the term "nested" is debatable here.

It's possible to concoct valid sources that somewhat
resemble nested comments, e.g.

int i = 1
/* outer comment
/* inner comment */
*//
0;

.... whose effect is the same as `int i = 0;'.

 

[Leor Zolman]

Leor Zolman wrote:

[ snip all ]

What would be the harm in a compiler allowing and supporting nested
comments? Even though Standard C doesn't support it, is a conforming
compiler required to diagnose it as an error?

The compiler is not required to issue a diagnostic when
`/*' appears inside a comment, if that's what you mean. On
the other hand, the compiler must diagnose `/* /* */ */'
because the comment ends at the first `*/', and the second
`*/' is a syntax error.

With C99, of course, nested comments are perfectly legal:

/* This is an outer comment ...
// ... containing a nested comment ...
... and then the outer comment continues */

However, the use of the term "nested" is debatable here.

It's possible to concoct valid sources that somewhat
resemble nested comments, e.g.

int i = 1
/* outer comment
/* inner comment */
*//
0;

... whose effect is the same as `int i = 0;'.

I did /not/ need to see that
-leor

 

[Rob Thorpe]

Probably because back in pre-historic times it was much easier to
parse. We read the sequence "/*", discard it, and read source
until the sequence "*/" appears, returning a single blank. No
need to count things, save things, whatever.

It remains easier to parse.

Disallowing nested comments has one key advantage:

If they are disallowed then C comments can be described with a regular
expression.

This makes it easier to use grep, awk, or your editors regexp replace
on your code.

The only significant problems with the practice of using
#if 0
#endif

is that it looks strange. It's good that there are now editors that
can deal with it visually.

 

[August Derleth]

Disallowing nested comments has one key advantage:

If they are disallowed then C comments can be described with a regular
expression.

True regexes can't match nested structures because they can't describe
recursion. (They aren't Turing-complete, in other words.) This is one
reason why the language-theoretic `pure regexes' suck.

Perl regexes, on the other hand, /can/ match nested structures. This is a
fundamental departure from theory, of course, and it relies on the ability
to assign a regex to a value and then refer to that value within the regex
itself. This is one reason why Perl regexes are called `patterns' in that
text, and it could allow hideously complex Perl patterns to do the work of
less hideous Perl programs.

(On the upside, Perl patterns are probably at least as powerful as BNF
now, which could lead to some interesting compiler design decisions.)

The example:

my $np;
$np = qr{
\(
(?:
(?> [^()]+ ) # Non-parens without backtracking.
|
(??{ $np }) # Group with matching parens.
)*
\)
}x;

my $funpat = qr/\w+$np/;
'myfun(1, (2*(3+4)),5)' =~ /^$funpat$/; # Matches!

This makes it easier to use grep, awk, or your editors regexp replace
on your code.

Perl is, on most *nix systems, at least as common as the GNU coreutils (or
their non-free equivalents). The disk images for PDP-11 V7 UNIX I
downloaded last night didn't have it, but I suppose us antiquarians must
make concessions to unpleasant realities.

In any case, a simple bison (or yacc) program (with a flex/lex frontend)
can trivially match nested comments.

But, in the general case, you are absolutely correct: The standard text
utilities use regexes that are fairly close to the language-theoretic
ones, and therefore can't handle recursion correctly. But making language
design decisions on that basis alone seems rather sideways.

 

[Arthur J. O'Dwyer]

"Makes hackers smile" makes hackers smile.

"Is the first half of this quine" is the first half of this quine.

;-)

-Arthur,
as long as the [OT] tag is already there

 

[Michael Wojcik]

Breaks existing code. I've seen source where several lines, each
ending with a comment, are commented out by replacing the first two
characters (which were spaces) with "/*". For example:

/* x = foo(); /* get result of foo */

While I certainly don't *recommend* that, it is existing practice,
and changes to the standard usually seek to minimize adverse
effects on existing code.

And both are a pain compared to simply commenting out sections of code;

I don't see how inserting a

#if 0

and a

#endif

is any more trouble than inserting comment delimiters. It's a grand
total of 9 more characters (10 if you count the newlines, but
commenting out code without putting the delimiters on a separate
line is a barbarism not to be contemplated).

say, if you're trying to play with two alternate forms of a construct, and
don't wish to have to go "formalize" the process with a preprocessor
symbol, etc. etc. ad nauseam.

#if 0 is *better* than a comment for trying two different forms,
since you can put them into the two halves of a #if / #else and
switch between them by changing a single character (0 becomes 1).

If by "preprocessor symbol" you mean a macro as the operand of
the "defined" operator (or of #ifdef), none is required. But you
*can* use one if you'd like to be able to select which form you're
using without editing the source (in typical implementations) - a
luxury not available if you use comments to remove code.

With nested comments, I can have any ole' broken, half-baked code in there,
and that's exactly what I /do/ want to be able to have in there.

So long as it's a string of legal pp-tokens, you can do the same
with #if 0. No need for it to be legal C code.

--
Michael Wojcik (e-mail address removed)

Q: What is the derivation and meaning of the name Erwin?
A: It is English from the Anglo-Saxon and means Tariff Act of 1909.
-- Columbus (Ohio) Citizen