By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,005 Members | 2,311 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,005 IT Pros & Developers. It's quick & easy.

// vs /*

P: n/a
Hi,

Is using // for a comment standard C?

Thanks,
Joe
Jun 21 '06 #1
Share this Question
Share on Google+
59 Replies


P: n/a
Joe Van Dyk wrote:
Hi,

Is using // for a comment standard C?


It was standardized in C99 although it was widely supported as a common
extension before that time. It is probably the most widely supported
C99 feature.

Robert Gamble

Jun 21 '06 #2

P: n/a
Robert Gamble wrote:
Joe Van Dyk wrote:
Hi,

Is using // for a comment standard C?

It was standardized in C99 although it was widely supported as a common
extension before that time. It is probably the most widely supported
C99 feature.


That's what I thought.

(I'm converting all our comments to be doxygen-compatible and I prefer
to use ///.)

Thanks,
Joe
Jun 21 '06 #3

P: n/a
Robert Gamble wrote:
Joe Van Dyk wrote:

Is using // for a comment standard C?


It was standardized in C99 although it was widely supported as a
common extension before that time. It is probably the most widely
supported C99 feature.


It is also highly unwise to use it in any media (such as usenet)
where line wrapping can occur.

--
"I don't know where bin Laden is. I have no idea and really
don't care. It's not that important." - G.W. Bush, 2002-03-13
"No, we've had no evidence that Saddam Hussein was involved
with September the 11th." - George Walker Bush 2003-09-17
Jun 21 '06 #4

P: n/a
Joe Van Dyk wrote:
Robert Gamble wrote:
Joe Van Dyk wrote:

Is using // for a comment standard C?


It was standardized in C99 although it was widely supported as a
common extension before that time. It is probably the most widely
supported C99 feature.


That's what I thought.

(I'm converting all our comments to be doxygen-compatible and I
prefer to use ///.)


Not considered wise from a portability viewpoint.

--
"I don't know where bin Laden is. I have no idea and really
don't care. It's not that important." - G.W. Bush, 2002-03-13
"No, we've had no evidence that Saddam Hussein was involved
with September the 11th." - George Walker Bush 2003-09-17

Jun 21 '06 #5

P: n/a
CBFalconer wrote:
Joe Van Dyk wrote:
Robert Gamble wrote:
Joe Van Dyk wrote:
Is using // for a comment standard C?
It was standardized in C99 although it was widely supported as a
common extension before that time. It is probably the most widely
supported C99 feature.

That's what I thought.

(I'm converting all our comments to be doxygen-compatible and I
prefer to use ///.)


Not considered wise from a portability viewpoint.

gcc continues to support both a pre-processor which does not process //
comments, and one which does.
Jun 21 '06 #6

P: n/a
On Tue, 20 Jun 2006 23:41:23 -0400, CBFalconer <cb********@yahoo.com>
wrote:
Robert Gamble wrote:
Joe Van Dyk wrote:

Is using // for a comment standard C?


It was standardized in C99 although it was widely supported as a
common extension before that time. It is probably the most widely
supported C99 feature.


It is also highly unwise to use it in any media (such as usenet)
where line wrapping can occur.


Iif you stuff a really long comment in a single line, you may be
flagged for having very poor coding/commenting style, but it is no
good reason to abandon the use of //

Zara
Jun 21 '06 #7

P: n/a
Zara wrote:
On Tue, 20 Jun 2006 23:41:23 -0400, CBFalconer <cb********@yahoo.com>
wrote:
Robert Gamble wrote:
Joe Van Dyk wrote:

Is using // for a comment standard C?

It was standardized in C99 although it was widely supported as a
common extension before that time. It is probably the most widely
supported C99 feature.


It is also highly unwise to use it in any media (such as usenet)
where line wrapping can occur.


Iif you stuff a really long comment in a single line, you may be
flagged for having very poor coding/commenting style, but it is no
good reason to abandon the use of //


Is there any good reason to adopt its use? Code should not
depend on white-space between tokens. IMO, using '\n' as the
comment termination character is one of the top 10 really bad
ideas in the history of computing.

Jun 21 '06 #8

P: n/a
"Bill Pursell" <bi**********@gmail.com> writes:
Zara wrote:
On Tue, 20 Jun 2006 23:41:23 -0400, CBFalconer <cb********@yahoo.com>
wrote:
>Robert Gamble wrote:
>> Joe Van Dyk wrote:
>>>
>>> Is using // for a comment standard C?
>>
>> It was standardized in C99 although it was widely supported as a
>> common extension before that time. It is probably the most widely
>> supported C99 feature.
>
>It is also highly unwise to use it in any media (such as usenet)
>where line wrapping can occur.


Iif you stuff a really long comment in a single line, you may be
flagged for having very poor coding/commenting style, but it is no
good reason to abandon the use of //


Is there any good reason to adopt its use? Code should not
depend on white-space between tokens. IMO, using '\n' as the
comment termination character is one of the top 10 really bad
ideas in the history of computing.


printf("Hello,
world\n");

Personally, I really like end-of-line comments ("//" in C99 and C++,
"#" in Perl and shell scripting, "--" in Ada). It's easy to comment
out large blocks of code given a decent editor, there's no ambiguity
about nested comments, and if you're looking at the middle of a large
comment block there's no question that it's in a comment block.

But of course it's a matter of taste, and I don't expect to convince
anyone.

One good reason to avoid // comments, as much as I like them, is that
they're not universally supported; another is the Usenet line-wrapping
problem. But the latter could be easily addressed by keeping your
lines reasonably short so they don't wrap.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 21 '06 #9

P: n/a
Joe Van Dyk said:
Hi,

Is using // for a comment standard C?


Yes and no. Several reasons have been given for avoiding them in your C90
programs, but nobody appears to have mentioned the fact that modding down
ANSI conformance to allow them will, in some implementations, also
necessarily involve removing some other diagnostic messages. For example,
on the implementation I use most during development, enabling // comments
involves disabling a great many ANSI conformance checks. It's too high a
price.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 21 '06 #10

P: n/a
In article <44***************@yahoo.com>,
CBFalconer <cb********@maineline.net> wrote:
....
It is also highly unwise to use it in any media (such as usenet)
where line wrapping can occur.


Damn unwise!

(heh heh)

Jun 21 '06 #11

P: n/a

Tim Prince wrote:
CBFalconer wrote:
Joe Van Dyk wrote:
Robert Gamble wrote:
Joe Van Dyk wrote: Is using // for a comment standard C?
It was standardized in C99 although it was widely supported as a
common extension before that time. It is probably the most widely
supported C99 feature.
That's what I thought.

(I'm converting all our comments to be doxygen-compatible and I
prefer to use ///.)


Not considered wise from a portability viewpoint.

gcc continues to support both a pre-processor which does not process //
comments, and one which doe


so what? All the world is not GCC.

--
Nick Keighley

Jun 21 '06 #12

P: n/a
In article <11**********************@g10g2000cwb.googlegroups .com>,
Nick Keighley <ni******************@hotmail.com> wrote:
....
gcc continues to support both a pre-processor which does not process //
comments, and one which doe


so what? All the world is not GCC.


I assume that if I pointed out that Nabisco makes at least 2 kinds of
Oreos, you'd "smartly" point out that "All the world is not Nabisco".

Jun 21 '06 #13

P: n/a
ga*****@xmission.xmission.com (Kenny McCormack) wrote:
In article <11**********************@g10g2000cwb.googlegroups .com>,
Nick Keighley <ni******************@hotmail.com> wrote:
...
gcc continues to support both a pre-processor which does not process //
comments, and one which doe


so what? All the world is not GCC.


I assume that if I pointed out that Nabisco makes at least 2 kinds of
Oreos, you'd "smartly" point out that "All the world is not Nabisco".


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

Richard
Jun 21 '06 #14

P: n/a
Richard Heathfield wrote:
Joe Van Dyk said:

Hi,

Is using // for a comment standard C?

Yes and no. Several reasons have been given for avoiding them in your C90
programs, but nobody appears to have mentioned the fact that modding down
ANSI conformance to allow them will, in some implementations, also
necessarily involve removing some other diagnostic messages. For example,
on the implementation I use most during development, enabling // comments
involves disabling a great many ANSI conformance checks. It's too high a
price.


Hm. What implementations might it hinder ANSI conformance checking?

Thanks,
Joe
Jun 21 '06 #15

P: n/a
Richard Bos wrote:
ga*****@xmission.xmission.com (Kenny McCormack) wrote:

In article <11**********************@g10g2000cwb.googlegroups .com>,
Nick Keighley <ni******************@hotmail.com> wrote:
...
gcc continues to support both a pre-processor which does not process //
comments, and one which doe

so what? All the world is not GCC.


I assume that if I pointed out that Nabisco makes at least 2 kinds of
Oreos, you'd "smartly" point out that "All the world is not Nabisco".

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


Mm.... oreos.
Jun 21 '06 #16

P: n/a
Joe Van Dyk <jo********@boeing.com> wrote:
Hm. What implementations might it hinder ANSI conformance checking?


I'm fairly sure Richard uses gcc; passing -ansi to the compiler both
disables support for // comments and enables all sorts of other
conformance checks that, as Richard pointed out, are more or less
indispensable.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Jun 21 '06 #17

P: n/a
In article <44*****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
ga*****@xmission.xmission.com (Kenny McCormack) wrote:
In article <11**********************@g10g2000cwb.googlegroups .com>,
Nick Keighley <ni******************@hotmail.com> wrote:
...
>> gcc continues to support both a pre-processor which does not process //
>> comments, and one which doe
>
>so what? All the world is not GCC.


I assume that if I pointed out that Nabisco makes at least 2 kinds of
Oreos, you'd "smartly" point out that "All the world is not Nabisco".


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


And who but a paranoid freak would try to draw such a ridiculous
inference?

Jun 21 '06 #18

P: n/a

Joe Van Dyk wrote:
Hi,

Is using // for a comment standard C?


Use /* */ comments.

Many CC's still don't support //. Mostly because they're C90
compilers.

So instead of going through your code and converting all /* */ to // or
/// just use

/** Doxy comment */

And save yourself a big f'ing headache.

Tom

Jun 21 '06 #19

P: n/a
On Wed, 21 Jun 2006 06:05:19 GMT, Keith Thompson <ks***@mib.org> wrote:
Personally, I really like end-of-line comments ("//" in C99 and C++,
"#" in Perl and shell scripting, "--" in Ada). It's easy to comment
out large blocks of code given a decent editor, there's no ambiguity
about nested comments, and if you're looking at the middle of a large
comment block there's no question that it's in a comment block.
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.

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

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 //. Apropos of your third
comment, the only difference here between these two is now that for the
former, this is a convention, and for the latter, this is a standard.
Nonetheless, if you are using an editor to create large comments it will
enforce its own conventions consistently.
But of course it's a matter of taste, and I don't expect to convince
anyone.


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

--
Ryan Reich
ry********@gmail.com
comp.lang.c
Jun 21 '06 #20

P: n/a
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:Th*************@gmail.com>

Jun 21 '06 #21

P: n/a
On Wed, 21 Jun 2006 13:41:53 -0400, Kenneth Brody <ke******@spamcop.net>
wrote:
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.

--
Ryan Reich
ry********@gmail.com
comp.lang.c
Jun 21 '06 #22

P: n/a

Kenneth Brody wrote:
/* 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!!

Jun 21 '06 #23

P: n/a
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
ga*****@xmission.xmission.com (Kenny McCormack) wrote:
In article <11**********************@g10g2000cwb.googlegroups .com>,
Nick Keighley <ni******************@hotmail.com> wrote:
...
>> gcc continues to support both a pre-processor which does not process //
>> comments, and one which doe
>
>so what? All the world is not GCC.


I assume that if I pointed out that Nabisco makes at least 2 kinds of
Oreos, you'd "smartly" point out that "All the world is not Nabisco".


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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 21 '06 #24

P: n/a
Ryan Reich <ry********@gmail.com> writes:
On Wed, 21 Jun 2006 06:05:19 GMT, Keith Thompson <ks***@mib.org> wrote:
Personally, I really like end-of-line comments ("//" in C99 and C++,
"#" in Perl and shell scripting, "--" in Ada). It's easy to comment
out large blocks of code given a decent editor, there's no ambiguity
about nested comments, and if you're looking at the middle of a large
comment block there's no question that it's in a comment block.
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.

[...]
But of course it's a matter of taste, and I don't expect to convince
anyone.


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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 21 '06 #25

P: n/a
Kenneth Brody <ke******@spamcop.net> writes:
[...]
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 21 '06 #26

P: n/a
Keith Thompson said:
Kenneth Brody <ke******@spamcop.net> writes:
[...]
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.


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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 21 '06 #27

P: n/a

Keith Thompson wrote:
Ryan Reich <ry********@gmail.com> writes:
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.


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.

Jun 21 '06 #28

P: n/a
Richard Heathfield <in*****@invalid.invalid> writes:
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? */
--
A competent C programmer knows how to write C programs correctly,
a C expert knows enough to argue with Dan Pop, and a C expert
expert knows not to bother.
Jun 21 '06 #29

P: n/a
Bill Pursell said:

Keith Thompson wrote:
Ryan Reich <ry********@gmail.com> writes:
> 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.


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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 21 '06 #30

P: n/a
Ben Pfaff wrote:
Richard Heathfield <in*****@invalid.invalid> writes:
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? */


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;
}

Jun 21 '06 #31

P: n/a
Ben Pfaff said:
Richard Heathfield <in*****@invalid.invalid> writes:
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? */


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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 21 '06 #32

P: n/a
On 2006-06-21, Harald van Dijk <tr*****@gmail.com> wrote:
Ben Pfaff wrote:
Richard Heathfield <in*****@invalid.invalid> writes:
> 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? */


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 */

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.
Jun 21 '06 #33

P: n/a
Richard Heathfield <in*****@invalid.invalid> writes:
[...]
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 21 '06 #34

P: n/a
On Wed, 21 Jun 2006 20:57:18 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:
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
Jun 21 '06 #35

P: n/a
On 2006-06-21, Mark McIntyre <ma**********@spamcop.net> wrote:
On Wed, 21 Jun 2006 20:57:18 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:
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?


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.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.
Jun 21 '06 #36

P: n/a
Keith Thompson said:
Richard Heathfield <in*****@invalid.invalid> writes:
[...] <snip>
#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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 21 '06 #37

P: n/a
Mark McIntyre said:
On Wed, 21 Jun 2006 20:57:18 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:
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?


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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 21 '06 #38

P: n/a
Bill Pursell wrote:

Kenneth Brody wrote:
/* 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!!


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:Th*************@gmail.com>
Jun 22 '06 #39

P: n/a
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:Th*************@gmail.com>

Jun 22 '06 #40

P: n/a
Kenneth Brody said:
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?)


Yes. Line-splicing happens in Translation Phase 2, whereas comment removal
doesn't happen until Translation Phase 3.

The reason I mentioned Win32 is only that its gerharsterly habit of using
the \ character as a path separator makes it more likely for such comments
to appear in Win32 programs. Other platforms are not immune by any means.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 22 '06 #41

P: n/a
Richard Heathfield wrote:
Bill Pursell said:
Keith Thompson wrote:
Ryan Reich <ry********@gmail.com> writes:

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


That's a beautiful little code snippet.
I think that some of the nested comment code is also fit for use in the
IOCCC.
Regarding #if and it's disadvantages, I would point out that you can do
both.
That is if you do:-
#if 0
/*
.... code ...
/*
#endif

Then the problem with nested parens AFAIK does not occur. An if you
have a colouring editor it will recognise the comment.

I don't do this though, I use an editor that recognises #ifs.

Jun 22 '06 #42

P: n/a
On Wed, 21 Jun 2006 23:29:28 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:
Mark McIntyre said:
On Wed, 21 Jun 2006 20:57:18 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:
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?


Any compiler is allowed to accept void main as an extension.


Sure, but thats not the point, is it?

Anyway, I'll remember you said this, sometime.... :-)

--
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
Jun 22 '06 #43

P: n/a
Kenneth Brody wrote:
.... snip ...
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 */


All adequately handled by the simple rule "after /* everything up
to and including a */ is comment". Similarly, "after // everything
up to end-of-line is comment".

--
Chuck F (cb********@yahoo.com) (cb********@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!
Jun 22 '06 #44

P: n/a
Mark McIntyre said:
On Wed, 21 Jun 2006 23:29:28 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:
Mark McIntyre said:
On Wed, 21 Jun 2006 20:57:18 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

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?
Any compiler is allowed to accept void main as an extension.


Sure, but thats not the point, is it?


Um, yes it is, actually.
Anyway, I'll remember you said this, sometime.... :-)


To save you the trouble, just remember 1.7 COMPLIANCE instead:

"A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any strictly
conforming program."
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 22 '06 #45

P: n/a
Kenneth Brody <ke******@spamcop.net> wrote:
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? */
This is an obvious syntax error under either version of the Standard. In
C89, there is no valid parse for // just after a ;, whereas in C99, the
*/ closes a comment that has never started, since after //, everything,
including /*, is ignored up to the end of the line.
Or:

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


This is valid C under both Standards. After /*, everything, including
//, is ignored up to the next */.

Correctly parsing (i.e., ignoring) comment markers within string or
character constants is no harder. The fun (FSVO) starts when you take
escape sequences into account. The worst case, which still isn't very
bad, is a string literal containing an escape sequence for " which
involves the trigraph for \, with a line splice inside it, and followed
by a comment opener which should be ignored.

Richard
Jun 23 '06 #46

P: n/a
CBFalconer <cb********@yahoo.com> writes:
Kenneth Brody wrote:
... snip ...

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 */


All adequately handled by the simple rule "after /* everything up
to and including a */ is comment". Similarly, "after // everything
up to end-of-line is comment".


So you agree that it is confusing? And that the order of the rules is
all important here? Since clearly the first "i++" line could employ
either one and unless there is a precedence given to the "/*" one then
the lines following are in error.

--
Chuck F (cb********@yahoo.com) (cb********@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!


--
Jun 23 '06 #47

P: n/a
"Richard G. Riley" <rg*****@gmail.com> wrote:
CBFalconer <cb********@yahoo.com> writes:
Kenneth Brody wrote:
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 */
All adequately handled by the simple rule "after /* everything up
to and including a */ is comment". Similarly, "after // everything
up to end-of-line is comment".


So you agree that it is confusing? And that the order of the rules is
all important here?


No, he doesn't (I can only suppose), and no, he doesn't (because it is
not).
Since clearly the first "i++" line could employ either one and unless
there is a precedence given to the "/*" one then the lines following are in error.


No, it couldn't, and there is no precedence given to either kind of
comment. Both are equally commentable. Whichever comment marker is
already part of another, enclosing comment is ignored, regardless of the
type of either comment. IOW, in all these cases:

code; // comment // comment
code; // comment /* comment
code; /* comment // comment */
code; /* comment /* comment */

the first comment marker starts the comment; the second comment marker
is ignored; the end of the line in the case of // comments, or */ in the
case of /* comments, ends the comment. Perfectly similar; perfectly
symmetrical; perfectly clear.

Where on earth is the problem?

Richard
Jun 23 '06 #48

P: n/a
On Thu, 22 Jun 2006 23:14:05 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:
To save you the trouble, just remember 1.7 COMPLIANCE instead:


No need, I can read AND remember stuff.

My point wasn't that. I think you got it though.
--
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
Jun 23 '06 #49

P: n/a

Richard Heathfield wrote:
Joe Van Dyk said:
Hi,

Is using // for a comment standard C?


Yes and no. Several reasons have been given for avoiding them in your C90
programs, but nobody appears to have mentioned the fact that modding down
ANSI conformance to allow them will, in some implementations, also
necessarily involve removing some other diagnostic messages. For example,
on the implementation I use most during development, enabling // comments
involves disabling a great many ANSI conformance checks. It's too high a
price.


Surely it's a simple matter for an experienced C
programmer such as yourself to write a small
program that filters them out and still lets you
use a C90 compiler. Or is this just more anti-C99
bias?

Jun 24 '06 #50

59 Replies

This discussion thread is closed

Replies have been disabled for this discussion.