Why don't C comments nest?

[BartC]

No, because the formal language allowed within the comment excludes the
digraph */ which may occur in the source code of C, inside a string
literal, as part of a comment, or inside a // comment.

Well, yes; I mentioned */ a sentence or two later.

It's more than a style issue; it's a formal language issue. Comments can
only
contain a subset of the possible set of C strings.

It is useful that you can have a subset of C within comments, for
instance,
coding examples. They just can't have /*...*/ comments of their own, which
is
fine since they are already inside a comment which can explain everything.

What you're saying then is that /*...*/ comments are not a suitable
mechanism for commenting out code? The reason being that code might contain
(in perhaps one program in a thousand) a '*/' or "*/" token? Yet everyone
does this, and the world hasn't yet ended.

And perhaps /*...*/ isn't suitable for writing comments, period, since there
will from time to time be content that will break it. For example I couldn't
paste */this sentence/* into such a comment. Yet that doesn't bother many
people either.

A mechanism for commenting out arbitrary code must be robust, period. This
way
it can be applied to a 50,000 line piece of source code without worry that
anything breaks.

#if 0 ... #endif satisfies that requirement.

Only if the code you're trying to 'comment out' is well-formed. If it's
unfinished, has open literals, and unbalanced #endifs scattered about, then
there will be problems. In this case /*...*/ might be a better bet...

 

[Willem]

Keith Thompson wrote:
)> Which is why I have changed my preference to writing this:
)>
)> some_function(10 /* param1 */
)> ,20 /* param2 */
)> #if 0
)> ,30 /* param3 */
)> #endif
)> );
)>
)> And not only in C, but in almost any language.
)>
)> The point is that this plays a lot nicer with revision control systems,
)> because adding or removing an argument is a 1-line change, whereas in the
)> other case it can potentially change the previous line as well.
)
) And if you want to comment out the *first* argument?
)
) I see your point, but personally I find that layout rather hard on
) my eyes. The need to comment out a single parameter is rare enough
) that I don't think it's worth it.

And the need to play nice with revision control systems ?
I do it a lot more for the benefit of version control than anything else
(though commenting out is a very rudimentary form of version control.)

If the language did allow a trailing comma, it wouldn't be an issue,
and even a change on the first argument would not be a problem:

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

Not allowing trailing commas means you wither get in trouble for the first
argument, or the last argument. Oh, and it makes automatic code generation
a tiny bit harder as well (generating JSON has the same problem).

So I would be all in favour of this feature.
Is there any possible (existing) code that this would break ?
AFAIK, it will turn something that was a syntax error into good code.
(It may even be that existing implementations are allowed to let you off
with a warning and generate code as if the trailing comma weren't there.)


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Stephen Sprunk]

Do you think `*;' should be valid?

(If so, how many operands have been omitted? ;-)

Amusing, but sort of misses the point since it hinges on _how_ "," is
defined rather than defending _why_ it is so defined.

Absent side effects, "x,y;" is equivalent to "y;". The expression ""
cannot have side effects, so ",y;" should also be equivalent to "y;" and
therefore be valid.

Absent side effects, ",y;" is equivalent to ";". The expression ""
cannot have side effects, so ",;" should also be equivalent to ";" and
therefore valid.

Absent side effects, "x,;" is equivalent to "x;". The expression ""
cannot have side effects, so "x,;" should also be equivalent to ";" and
therefore valid.

The problem is that both operands must be evaluated by the operator
before it can discard the results, and the current language definition
does not define how to evaluate a null expression. However, what if it did?

This is similar to not allowing objects of type void; such an object is
obviously meaningless, but there are certain corner cases where
uniformity matters more than meaning.

S

 

[Jorgen Grahn]

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).

This is not an answer, but IMNSHO:

Commenting out code is almost always a mistake. Either
(a) read the code and reason about it until you can make it right
or
(b) remove it and pick it up from version control or the undo feature
of your editor if it turns out you really need it

At the other extreme, when people leave commented-out code in
committed code (code they feel is ready to share with others) you can
be reasonably sure that something is very wrong.

/Jorgen

 

[Keith Thompson]

What you're saying then is that /*...*/ comments are not a suitable
mechanism for commenting out code? The reason being that code might contain
(in perhaps one program in a thousand) a '*/' or "*/" token? Yet everyone
does this, and the world hasn't yet ended.

/*...*/ comments are not a suitable mechanism for commenting out code
because code often includes its own /*...*/ comments, and they don't
nest.

Most of the issues involving '*/' or "*/" tokens don't even arise until
you start talking about changing the language to allow /*...*/ comments
to nest, and any such change would break existing code.

It's been mentioned several times that changing the language to allow
/*...*/ comments to nest would break existing code. If you've ever
acknowledged that very important point, I've missed it.

 

[Keith Thompson]

Keith Thompson wrote:
)> Which is why I have changed my preference to writing this:
)>
)> some_function(10 /* param1 */
)> ,20 /* param2 */
)> #if 0
)> ,30 /* param3 */
)> #endif
)> );
)>
)> And not only in C, but in almost any language.
)>
)> The point is that this plays a lot nicer with revision control systems,
)> because adding or removing an argument is a 1-line change, whereas in the
)> other case it can potentially change the previous line as well.
)
) And if you want to comment out the *first* argument?
)
) I see your point, but personally I find that layout rather hard on
) my eyes. The need to comment out a single parameter is rare enough
) that I don't think it's worth it.

And the need to play nice with revision control systems ?
I do it a lot more for the benefit of version control than anything else
(though commenting out is a very rudimentary form of version control.)

Revision control systems can fend for themselves. If they end up
storing an extra line or two of diffs, that's not much of a problem.
Diff tools can be configured to show a few lines of context around each
change; some do so by default.

If the language did allow a trailing comma, it wouldn't be an issue,
and even a change on the first argument would not be a problem:

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

Not allowing trailing commas means you wither get in trouble for the first
argument, or the last argument. Oh, and it makes automatic code generation
a tiny bit harder as well (generating JSON has the same problem).

So I would be all in favour of this feature.
Is there any possible (existing) code that this would break ?
AFAIK, it will turn something that was a syntax error into good code.
(It may even be that existing implementations are allowed to let you off
with a warning and generate code as if the trailing comma weren't there.)

A syntax error, like a constraint violation, merely requires the
compiler to issue a diagnostic. What it does after that is undefined.

More realistically, perhaps, a compiler could permit trailing commas in
a non-conforming mode (most compilers are non-conforming by default
anyway).

 

[Willem]

Keith Thompson wrote:
)> And the need to play nice with revision control systems ?
)> I do it a lot more for the benefit of version control than anything else
)> (though commenting out is a very rudimentary form of version control.)
)
) Revision control systems can fend for themselves. If they end up
) storing an extra line or two of diffs, that's not much of a problem.
) Diff tools can be configured to show a few lines of context around each
) change; some do so by default.

It's the merging where the problems start. I know, I've seen it happen.
Enough times for me to change my preference to the comma at the start of
theline, which would have avoided those merge conflicts.

)> So I would be all in favour of this feature.
)> Is there any possible (existing) code that this would break ?
)> AFAIK, it will turn something that was a syntax error into good code.
)> (It may even be that existing implementations are allowed to let you off
)> with a warning and generate code as if the trailing comma weren't there.)
)
) A syntax error, like a constraint violation, merely requires the
) compiler to issue a diagnostic. What it does after that is undefined.

So yes, they are allowed to let you off with a warning?
AFAIK, an implementation can define what it does in the case of certain
undefined behaviour. So, here's to compiler writers: make it a warning!

) More realistically, perhaps, a compiler could permit trailing commas in
) a non-conforming mode (most compilers are non-conforming by default
) anyway).

If enough compilers permit it, it would go into the next standard.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[James Kuyper]

Keith Thompson wrote: ....
) A syntax error, like a constraint violation, merely requires the
) compiler to issue a diagnostic. What it does after that is undefined.

So yes, they are allowed to let you off with a warning?
AFAIK, an implementation can define what it does in the case of certain
undefined behaviour.

You can drop the word "certain" there, It is always the case that if the
behavior is undefined, the C standard imposes no restrictions, leaving
an implementation free to provide its own definition.

 

[Willem]

James Kuyper wrote:
) On 11/13/2011 05:30 AM, Willem wrote:
)> Keith Thompson wrote:
) ...
)> ) A syntax error, like a constraint violation, merely requires the
)> ) compiler to issue a diagnostic. What it does after that is undefined.
)>
)> So yes, they are allowed to let you off with a warning?
)> AFAIK, an implementation can define what it does in the case of certain
)> undefined behaviour.
)
) You can drop the word "certain" there, It is always the case that if the
) behavior is undefined, the C standard imposes no restrictions, leaving
) an implementation free to provide its own definition.

Yes, but the implementation can choose that it only does that for some
behaviours, and not for others. I see how the wording is confusing.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Phil Carmody]

That's rather a drastic measure. Especially if you've just downloaded some
source code and big chunks of it have been cut out! Rather difficult to
reinstate then.

For values of 'difficult' almost indistinguishable from 'trivial'

$ git reset --hard HEAD

Anyway suppose the commented lines are actually intended to be read?

"The" commented lines? Which commented lines? Your hypothetical is
purely in your own head currently. It's hard to suggest solutions to
problems unless they're unambiguously described. If there's no reason
to change the code you've been given, and it's valid code - then just
leave it alone. That's not, however, any justification for creating
new code that contains evidence of sloppy development practices.

Phil

 

[Ian Collins]

In such cases, I often use:

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

A little awkward, but "less ugly".

I still don't understand you anyone would do this.

Why not just remove the unused parameter?

 

[James Kuyper]

I still don't understand you anyone would do this.

To remind future maintainers that this function used to have an extra
feature, which might someday need to be reinstated. As a general rule,
it would be associated with commented-out code within the body of the
function that makes use of the parameter. Keeping this old code, rather
than relying solely on the revision-control system serves to prevent
people from forgetting about the feature.
I've done things like this during debugging, but not for delivered code.

 

[Ian Collins]

To remind future maintainers that this function used to have an extra
feature, which might someday need to be reinstated. As a general rule,
it would be associated with commented-out code within the body of the
function that makes use of the parameter. Keeping this old code, rather
than relying solely on the revision-control system serves to prevent
people from forgetting about the feature.

That path is fraught with danger. The commented out code will become
stale because no one would bother to maintain it (for how could it be
tested?). It is far better to leave the original, in context, on a
branch and keep the main line clean.

 

[BartC]

On 11/16/11 08:22 AM, Kenneth Brody wrote:

I still don't understand you anyone would do this.

Why not just remove the unused parameter?

Because commenting something out isn't the same as deleting it for good.

Have you never written experimental code?

Besides, as soon as you delete a nondescript piece of code, usually the
application will suddenly stop working. With the weaker commitment of a
commenting-out, you can reinstate the code very easily.

Or sometimes you want to replace one bit of code by a variation of it, but
you still need the original code visible to work from. If the new version is
not quite right, you again need the original to start again. Quite often
there will be something in a line that is causing a problem, and you
temporarily comment-out different bits to investigate it.

Anyway there are dozens of reasons why people want to have commented-out
code, I don't think anyone disputes that. (Except perhaps you with your
super-duper version control systems which can remember and recover any mod
you ever did; in which case why should you care what anyone else uses
comments for?)

I just happen to think that #if 0 is a ugly way of doing this (with a few
problems of it's own), while nested comments is an elegant way.

 

[Ian Collins]

Because commenting something out isn't the same as deleting it for good.

Have you never written experimental code?

Often, but it doesn't find its way into production code.

Besides, as soon as you delete a nondescript piece of code, usually the
application will suddenly stop working. With the weaker commitment of a
commenting-out, you can reinstate the code very easily.

Or in my case, the tests will fail and I'll revert the change.

Or sometimes you want to replace one bit of code by a variation of it, but
you still need the original code visible to work from. If the new version is
not quite right, you again need the original to start again. Quite often
there will be something in a line that is causing a problem, and you
temporarily comment-out different bits to investigate it.

If this happens during an editing session, use the editor's undo/redo
facility.

If I want to make a change while keeping the original, I either open the
parent version in another editor window, or more often, open a visual
diff which highlights the changes clearly.

Anyway there are dozens of reasons why people want to have commented-out
code, I don't think anyone disputes that. (Except perhaps you with your
super-duper version control systems which can remember and recover any mod
you ever did; in which case why should you care what anyone else uses
comments for?)

Using version control isn't rocket science. Subversion, git and
mercurial give you all the tools you need. They also integrate well
into the popular open source IDEs.

See my reply to James Kuyper, keeping stale, commented out code around
is as bad, if not worse, than having out of date design documents.

 

[Keith Thompson]

I just happen to think that #if 0 is a ugly way of doing this (with a few
problems of it's own), while nested comments is an elegant way.

It doesn't matter how elegant nested comments might or might not be.
They simply don't exist in C. I have yet to see you acknowledge that.

 

[Willem]

Ian Collins wrote:
) On 11/16/11 08:22 AM, Kenneth Brody wrote:
)> In such cases, I often use:
)>
)> some_function( 10 /* param1 */
)> ,20 /* param2 */
)> #if 0
)> ,30 /* param3 */
)> #endif
)> );
)>
)> A little awkward, but "less ugly".
)
) I still don't understand you anyone would do this.
)
) Why not just remove the unused parameter?

some_function( 10 /* param1 */
,20 /* param2 */
#ifdef EXTRA_PARAMS
,30 /* param3 */
#endif
);

Oh, and besides that, writing it like above makes it easier to avoid merge
conflicts in sources where parameters are often tacked on at the end.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[BartC]

OK, 'would be an' instead of 'is an'.

It doesn't matter how elegant nested comments might or might not be.
They simply don't exist in C. I have yet to see you acknowledge that.

Clearly they don't, for arbitrary levels of /*...*/ comments, otherwise this
thread wouldn't exist.

Although nested comments of sorts can be achieved to a limited extent with
some combination of /*...*/, // and #if 0.

 

[Ian Collins]

Ian Collins wrote:
) On 11/16/11 08:22 AM, Kenneth Brody wrote:
)> In such cases, I often use:
)>
)> some_function( 10 /* param1 */
)> ,20 /* param2 */
)> #if 0
)> ,30 /* param3 */
)> #endif
)> );
)>
)> A little awkward, but "less ugly".
)
) I still don't understand you anyone would do this.
)
) Why not just remove the unused parameter?

some_function( 10 /* param1 */
,20 /* param2 */
#ifdef EXTRA_PARAMS
,30 /* param3 */
#endif
);

In that case, why not

#ifdef EXTRA_PARAMS
some_function( 10, 20, 30 );
#else
some_function( 10, 20 );
#endif

rather than adopt a naff style for some calls?

Oh, and besides that, writing it like above makes it easier to avoid merge
conflicts in sources where parameters are often tacked on at the end.

So does my alternative.

 

[Kaz Kylheku]

[ ... ]

I just happen to think that #if 0 is a ugly way of doing this (with a few
problems of it's own), while nested comments is an elegant way.

I showed several times how a simple macro can do it this way within
one line:

#define IGN(...) /* C99 variadic */

some_function(10, 20, IGN(30, ) );

Nests and everything:

IGN( IGN ( ... ) IGN ( IGN ( ... ) ) )

A limitation is that the the stuff that is being commented out has to have
balanced parentheses. I could live with that.