Why don't C comments nest?

A

Al

Hi all,

(Apologies if this is in a FAQ somewhere, I couldn't find anything).

Almost every time I do any significant amount of coding in C or C++, I
end up wishing C-style comments would nest. It would make rapid
debugging much more convenient (vs. #if 0/#endif or editor macros).

Anyway, was this an explicit design decision, or some sort of historical
artifact? (e.g. too expensive to parse at the time). What other sorts of
reasons might exist against nesting comments?

Thanks!
-Al-
 
R

Richard Heathfield

Al said:
Hi all,

(Apologies if this is in a FAQ somewhere, I couldn't find anything).

Almost every time I do any significant amount of coding in C or C++, I
end up wishing C-style comments would nest. It would make rapid
debugging much more convenient (vs. #if 0/#endif or editor macros).

Personally, I find #if 0/#endif quicker and more intuitive. I prefer to
reserve comment syntax for actual comments on the code that there is,
rather than use it to create ghosts of the code that there isn't.
Anyway, was this an explicit design decision, or some sort of
historical artifact? (e.g. too expensive to parse at the time). What
other sorts of reasons might exist against nesting comments?

Neither the C Standard nor K&R2 have anything to say about the reasoning
behind this decision. The C Rationale, however, suggests that the ISO C
Committee managed to predict ahead of time that I wouldn't like the
idea of nested comments, and arranged matters such that I would not be
disappointed. It says:

The Committee considered proposals to allow comments to nest. The main
argument for nesting comments is that it would allow programmers to
``comment out'' code. The Committee rejected this proposal on the
grounds that comments should be used for adding documentation to a
program, and that preferable mechanisms already exist for source code
exclusion. For example,

#if 0
/* this code is bracketed out because ... */
code_to_be_excluded();
#endif

Preprocessing directives such as this prevent the enclosed code from
being scanned by later translation phases. Bracketed material can
include comments and other, nested, regions of bracketed code.

Another way of accomplishing these goals is with an if statement:

if (0) {
/* this code is bracketed out because ... */
code_to_be_excluded();
}

Many modern compilers will generate no code for this if statement.
 
E

Eric Sosman

Al said:
Hi all,

(Apologies if this is in a FAQ somewhere, I couldn't find anything).

This is Question 20.20 in the comp.lang.c Frequently
Asked Questions (FAQ) list at <http://c-faq.com/>. It is
hard to imagine how you could have missed it, since the
text of the question contains an *exact* replica of your
Subject line.
 
D

David T. Ashley

Al said:
Anyway, was this an explicit design decision, or some sort of historical
artifact? (e.g. too expensive to parse at the time). What other sorts of
reasons might exist against nesting comments?

Generally, the probability of a human making a mistake in interacting with a
certain type of system is correlated with how much state the system holds.

In terms of the probability that a person will make a mistake when using
nested comments, note that:

a)Without nested comments, the parser state is known after "*/". With
nested comments, it is not.

b)Nested comments provide more possibilites for a person to accidentally
comment out portions of code without realizing it (leading to severe bugs).

Of course, one could make the same argument with #if 0, but it seems to me
that the human eye just isn't very good at picking out "/*" and "*/" and
matching them up in a complex stream of characters.

I don't disagree with the decision to not support nested comments. It is
just one more path for accidents.
 
A

Al

Eric Sosman wrote:
This is Question 20.20 in the comp.lang.c Frequently
Asked Questions (FAQ) list at <http://c-faq.com/>. It is
hard to imagine how you could have missed it, since the
text of the question contains an *exact* replica of your
Subject line.

Ah, good catch, sorry about that. I was looking for a section about
Comments and didn't realize it was in Miscellaneous instead. So, I guess
it goes back further than C to PL/I and beyond.


Thanks,
-Al-
 
A

Army1987

Hi all,

(Apologies if this is in a FAQ somewhere, I couldn't find anything).

Almost every time I do any significant amount of coding in C or C++, I
end up wishing C-style comments would nest. It would make rapid
debugging much more convenient (vs. #if 0/#endif or editor macros).

Anyway, was this an explicit design decision, or some sort of historical
artifact? (e.g. too expensive to parse at the time).
I don't think that's the reason. I've never written a
preprocessor, but I think that to enable nested comments one would
just need a counting variable incremented for each /* and
decremented for each */, instead of a Boolean variable set and
reset. You might add a translation limit of "32767 nested
comments".

But they wouldn't be that useful. I agree with DTA.
 
H

Harald van =?UTF-8?B?RMSzaw==?=

Army1987 said:
I don't think that's the reason. I've never written a
preprocessor, but I think that to enable nested comments one would
just need a counting variable incremented for each /* and
decremented for each */, instead of a Boolean variable set and
reset. You might add a translation limit of "32767 nested
comments".

As simple as that is, it could be even simpler: preprocessors may have a
function designed specifically to skip comments. This function may already
check for /* to give a warning that C comments do not nest. (Both are true
in some preprocessors, but I of course cannot speak about all.) All it
would need to do is call itself recursively instead of giving this warning.
 
R

Roland Pibinger

Personally, I find #if 0/#endif quicker and more intuitive. I prefer to
reserve comment syntax for actual comments on the code that there is,
rather than use it to create ghosts of the code that there isn't.

But aren't the #if 0/#endif the 'ghosts' in the code? Comments are
visibly distinguished by most modern syntax-highlightning editors, #if
0/#endif sections not (unless you use the new Eclipse CDT 4.0 with
'Inactive Code Highlighting' http://preview.tinyurl.com/2jwaed).
Another way of accomplishing these goals is with an if statement:

if (0) {
/* this code is bracketed out because ... */
code_to_be_excluded();
}

Many modern compilers will generate no code for this if statement.

Modern compilers should create a warning for this code.

IMO, the best way to comment out lange sections of code are //
comments for which hotkeys are provided by many IDEs and editors.
 
C

Chris Dollin

Roland said:
Modern compilers should create a warning for this code.

So long as I can tell them DON'T DO THAT, that's OK.
IMO, the best way to comment out lange sections of code are //
comments for which hotkeys are provided by many IDEs and editors.

I agree that's an excellent suggestion, but it only works for
languages with // (or similar end-of-line) comments.
 
H

Harald van =?UTF-8?B?RMSzaw==?=

Chris said:
I agree that's an excellent suggestion, but it only works for
languages with // (or similar end-of-line) comments.

I think you mean "Such As C++ And C99 But Not C90/C89".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top