Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Why don't C comments nest? (http://www.velocityreviews.com/forums/t805817-why-dont-c-comments-nest.html)

Aron Packer 11-11-2011 07:21 PM

Why don't C comments nest?
 
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!

nroberts 11-11-2011 07:25 PM

Re: Why don't C comments nest?
 
On Nov 11, 11:21*am, Aron Packer <a...@rightthing.invalid> wrote:
> 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!


Well, it does make parsing a little easier. If you try to write a C-
comment remover, which I believe is an exercise in K&R, you'd probably
see why.

James Kuyper 11-11-2011 07:31 PM

Re: Why don't C comments nest?
 
On 11/11/2011 02:21 PM, Aron Packer wrote:
> 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?


The Rationale (Revision 5.1.0 April-2003) says:
> The C89 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 C89
> 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
> /* 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) {
> /* code to be excluded */
> }
>
> Many modern compilers will generate no code for this if statement.




Kaz Kylheku 11-11-2011 08:11 PM

Re: Why don't C comments nest?
 
On 2011-11-11, Aron Packer <atp1@rightthing.invalid> wrote:
> 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).


Rapid meaning, what you save a few keystrokes over #if 0?

> 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?


Consideration 1:

In order for comments to be suitable as a feature for commenting out code,
the language has to be defined differently. Firstly, /* and */ have to be
tokens. Secondly, the "commented out" material between the /* and */ tokens has
to also be delimited into tokens.

This way, for instance, the following will not break:

/* char *comment_end = "/*"; */

Here, "/*" is embedded in a string literal token and so loses
the comment-closing meaning.

If you don't have this kind of robustness, there is no point in allowing nested
comments.

Either solve the embedding problem 100% or don't bother.

Note that if you allow only tokens between /* and */, then it becomes
more difficult to write comments, which cannot be freeform text.

The #if 0 directive solves the embedding problem, because material which is
skipped by the preprocessor is still decomposed into tokens.
This is why we don't use it for writing comments.

The upshot is that /* */ is for writing comments and #if ... #endif
is for "compiling out" code you don't want.

Consideration 2:

Nesting C comments are not recognizeable by a finite automaton (regular
language). They require a push-down automaton or counter: something
to keep track of the nesting levels so every open /* is balanced
by a closing */.

This is a minor thing but it does mean that in a lexical analyzer generator
based on a tool like lex, you have to write dedicated code for C comments.
(This is sometimes done in practice anyway even for non-nesting comments,
because the regex for C comments is convoluted and ugly if the regex language
does not support advanced operators like a non-greedy Kleene star, or
complement.)

It is nevertheless a useful fact that C can be tokenized purely with regexes,
ugly or not, including the recognition of comments.

BartC 11-11-2011 08:28 PM

Re: Why don't C comments nest?
 
"Kaz Kylheku" <kaz@kylheku.com> wrote in message
news:20111111115530.783@kylheku.com...
> On 2011-11-11, Aron Packer <atp1@rightthing.invalid> wrote:
>> 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).

>
> Rapid meaning, what you save a few keystrokes over #if 0?
>
>> 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?

>
> Consideration 1:
>
> In order for comments to be suitable as a feature for commenting out
> code,
> the language has to be defined differently. Firstly, /* and */ have to be
> tokens. Secondly, the "commented out" material between the /* and */
> tokens has
> to also be delimited into tokens.


I don't think that's necessary, but you have to consider that */ inside a
string literal, or as part of a // comment, may cause problems.

> This way, for instance, the following will not break:
>
> /* char *comment_end = "/*"; */


> Here, "/*" is embedded in a string literal token and so loses
> the comment-closing meaning.


You mean "*/"? In which case you can't even write it whether you have nested
comments or not:

/* char *comment_end = "*/"; */

I've programmed nested comments in lexers before, and most of the time they
work fine. (It seems to be mostly commenting-out blocks of lexer code, which
is full of literals and comments to do with comment-processing, that cause
problems.)

> If you don't have this kind of robustness, there is no point in allowing
> nested
> comments.
> Either solve the embedding problem 100% or don't bother.


The above example (and a there are a few more) show that even normal
comments aren't 100% robust, so what's the difference? Nobody's going to be
forcing anyone to make use of them.

>
> Note that if you allow only tokens between /* and */, then it becomes
> more difficult to write comments, which cannot be freeform text.
>
> The #if 0 directive solves the embedding problem, because material which
> is


Perhaps have #comment ... #end then


> The upshot is that /* */ is for writing comments and #if ... #endif
> is for "compiling out" code you don't want.


Suppose the code you want to comment out is the middle of a line, which is
already using /*...*/ ?

--
Bartc



Keith Thompson 11-11-2011 09:16 PM

Re: Why don't C comments nest?
 
"BartC" <bc@freeuk.com> writes:
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
> news:20111111115530.783@kylheku.com...

[...]
>> The #if 0 directive solves the embedding problem, because material which
>> is

>
> Perhaps have #comment ... #end then


Hmm? What problem would #comment ... #end solve that #if 0 ... #endif
doesn't already solve?

>> The upshot is that /* */ is for writing comments and #if ... #endif
>> is for "compiling out" code you don't want.

>
> Suppose the code you want to comment out is the middle of a line, which is
> already using /*...*/ ?


Well then I guess you've got a bit of a problem. But I don't think I've
evern run into that situation.

Let's see if I can come up with a plausible example.

some_func(10 /* param1 */, 20 /* param2 */, 30 /* param3 */);

The comments are there to show the names of the actual parameters,
without which "some_func(10, 20, 30);" isn't nearly as clear.

Then some_func is changed so it only takes 2 parameters, but you want to
keep the information about the 3rd one in the source for some reason.

First, consider whether that's really worth doing. You can just delete
the third argument altogether:

some_func(10 /* param1 */, 20 /* param2 */);

and if you need to see the 3-argument version of the call, you can just
look in your source control system. (You *are* using one, right?)

But ok, let's say there's a good reason to keep the original version as
a comment. Here's how I might do it:

#if 0
some_func(10 /* param1 */, 20 /* param2 */, 30 /* param3 */);
#else
some_func(10 /* param1 */, 20 /* param2 */);
#endif

Any definition of how comments work (nesting vs. non-nesting,
single-line vs. end-of-line vs. partial-line vs. multi-line, etc.) is
going to be inconvenient for some purposes. None of these
inconveniences are insurmountable.

And of course changing the rules now would break existing code. I've
seen code that specifically depends on the fact that /**/ comments
*don't* nest.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

James Kuyper 11-11-2011 09:28 PM

Re: Why don't C comments nest?
 
On 11/11/2011 04:16 PM, Keith Thompson wrote:
> "BartC" <bc@freeuk.com> writes:

....
>> Suppose the code you want to comment out is the middle of a line, which is
>> already using /*...*/ ?

>
> Well then I guess you've got a bit of a problem. But I don't think I've
> evern run into that situation.
>
> Let's see if I can come up with a plausible example.
>
> some_func(10 /* param1 */, 20 /* param2 */, 30 /* param3 */);
>
> The comments are there to show the names of the actual parameters,
> without which "some_func(10, 20, 30);" isn't nearly as clear.
>
> Then some_func is changed so it only takes 2 parameters, but you want to
> keep the information about the 3rd one in the source for some reason.
>
> First, consider whether that's really worth doing. You can just delete
> the third argument altogether:
>
> some_func(10 /* param1 */, 20 /* param2 */);
>
> and if you need to see the 3-argument version of the call, you can just
> look in your source control system. (You *are* using one, right?)
>
> But ok, let's say there's a good reason to keep the original version as
> a comment. Here's how I might do it:
>
> #if 0
> some_func(10 /* param1 */, 20 /* param2 */, 30 /* param3 */);
> #else
> some_func(10 /* param1 */, 20 /* param2 */);
> #endif


My preference is

some_func(10 /* param1 */, 20 /* param2 */
#if 0
, 30 /* param3 */
#endif
);

But I can understand why some might consider that ugly.



Keith Thompson 11-11-2011 09:54 PM

Re: Why don't C comments nest?
 
James Kuyper <jameskuyper@verizon.net> writes:
> On 11/11/2011 04:16 PM, Keith Thompson wrote:

[...]
>> But ok, let's say there's a good reason to keep the original version as
>> a comment. Here's how I might do it:
>>
>> #if 0
>> some_func(10 /* param1 */, 20 /* param2 */, 30 /* param3 */);
>> #else
>> some_func(10 /* param1 */, 20 /* param2 */);
>> #endif

>
> My preference is
>
> some_func(10 /* param1 */, 20 /* param2 */
> #if 0
> , 30 /* param3 */
> #endif
> );
>
> But I can understand why some might consider that ugly.


If a comma were permitted after the last parameter declaration, you
could just write:

some_function(10 /* param1 */,
20 /* param2 */,
#if 0
30 /* param3 */,
#endif
);

C99 changed the syntax to permit a trailing comma in an enum
declaration. It would have made sense to permit a trailling
comma for *any* comma-separated list. (Probably not for the comma
operator, though.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

BartC 11-11-2011 10:14 PM

Re: Why don't C comments nest?
 
"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnobwi7421.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
>> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
>> news:20111111115530.783@kylheku.com...

> [...]
>>> The #if 0 directive solves the embedding problem, because material which
>>> is

>>
>> Perhaps have #comment ... #end then


> Hmm? What problem would #comment ... #end solve that #if 0 ... #endif
> doesn't already solve?


It's more self-explanatory than #if 0

>> Suppose the code you want to comment out is the middle of a line, which
>> is
>> already using /*...*/ ?

>
> Well then I guess you've got a bit of a problem. But I don't think I've
> evern run into that situation.
>
> Let's see if I can come up with a plausible example.


The problem is placing unnecessary restrictions on how C code is laid out.

Insisting on #if 0 means imposing a line-oriented structure, while C is
supposed to be free-format.

Besides, any example anyone comes up with, can be rewritten to use multiple
lines that would allow the use of #if 0. If which case, why bother having
/*...*/ comments at all?

The advantage of /*...*/ is starting and/or ending the comment in the middle
of a line. If that is desirable, why shouldn't one be able to do it on a
section of code (which could span multiple lines) which happens to already
have a comment in there?

Maybe there are several existing comments, some can be whole lines and some
partial. Or it's a massive bit of code and it may not be easy to check
whether there are comments there or not! But it shouldn't be necessary to
care.

--
Bartc


Ian Collins 11-11-2011 10:20 PM

Re: Why don't C comments nest?
 
On 11/12/11 09:28 AM, BartC wrote:
> "Kaz Kylheku"<kaz@kylheku.com> wrote:
>
>> The upshot is that /* */ is for writing comments and #if ... #endif
>> is for "compiling out" code you don't want.

>
> Suppose the code you want to comment out is the middle of a line, which is
> already using /*...*/ ?


Check in, remove code, compile, test and if required, revert.

--
Ian Collins


All times are GMT. The time now is 04:34 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.