// vs /*

[Richard Heathfield]

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.

 

[Rob Thorpe]

Bill Pursell said:

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

 

[CBFalconer]

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

 

[Mark McIntyre]

Mark McIntyre said:


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

 

[Richard Heathfield]

Mark McIntyre said:

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 Bos]

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

 

[Richard G. Riley]

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.

--

 

[Richard Bos]

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

 

[Mark McIntyre]

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

 

[ena8t8si]

Joe Van Dyk said:


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?

 

[Keith Thompson]

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?

Suppose I download a large software package containing, say, several
hundred source files. It might even be in a mix of different
languages. Suppose I only have a strict C90 compiler that doesn't
support "//" comments. If the C code doesn't use "//" comments, I
just do the usual unpack, configure, make, make install (or whatever).
If it does, I can't compile it without editing the source files.
However easy that is for a single file, I'm not likely to take the
time to write something that will do it recursively for the whole
package (unless I *really* need to build and install the package).

(As it happens, I've never run into this particular situation myself.)

 

[Andrew Poelstra]

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?

Good point. Perhaps Mr Heathfield should also color-code his
work in HTML so that it will display better in web browsers.
After all, an experienced C programmer like himself could
easily write a filter to remove it come compile time. Or is
that just more anti-internet bias?

 

[Richard Heathfield]

(e-mail address removed) said:

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.

Why would I need to write a filter? I don't put // comments into my source
in the first place! The place I encounter // comments most is right here in
comp.lang.c, in code written by people asking for help. If they want help
that badly, they can take the trouble to make their source compilable with
a C90 compiler.

Or is this just more anti-C99 bias?

Why would I be biased against something that, for most of us, doesn't even
exist? I am all in favour of C99 becoming as widespread as C90 currently
is. But until it gets to that stage, why would anyone interested in
portability bother to use it?

 

[jaysome]

(e-mail address removed) said:


Why would I need to write a filter? I don't put // comments into my source
in the first place!

Wow.

I have used // comments almost exlusively in my C code since 1996.
That was the year that Joe S. wrote a VC++ macro to format // comments
and I've been hooked ever since.

I love it that the compilers like gcc and VC++, inter alia, support //
comments in C90 code.

 

[Richard Heathfield]

jaysome said:

I have used // comments almost exlusively in my C code since 1996.
That was the year that Joe S. wrote a VC++ macro to format // comments
and I've been hooked ever since.

I love it that the compilers like gcc and VC++, inter alia, support //
comments in C90 code.

You need to turn up your warning level.

 

[Tom St Denis]

Wow.

I have used // comments almost exlusively in my C code since 1996.
That was the year that Joe S. wrote a VC++ macro to format // comments
and I've been hooked ever since.

I love it that the compilers like gcc and VC++, inter alia, support //
comments in C90 code.

Try working on a non-windows platform for a change.

You'll get on some hard to pronounce box like AIX or HP-UX and do a

cc -V

and get "copyright 1994" as a response...

Then you'll compile your code except it explodes because // isn't a
valid C90 comment.

I don't see why /* */ is so hard to write. You really ought to be
spending more time thinking about what to put in the comment then the
delimitters.

Tom

 

[Andrew Poelstra]

Try working on a non-windows platform for a change.

You'll get on some hard to pronounce box like AIX or HP-UX and do a

cc -V

and get "copyright 1994" as a response...

Then you'll compile your code except it explodes because // isn't a
valid C90 comment.

I don't see why /* */ is so hard to write. You really ought to be
spending more time thinking about what to put in the comment then the
delimitters.

Not to mention how much easier it is to format. I try to keep my comments
under a hundred characters or so (preferably 80, but space gets tight),
and typing /**/ and being able to fill that with whatever I want, including
newlines, is a big help.

jaysome:
gcc does not support // comments in c90 mode. Every time I compile with
them, I get diagnostics. Perhaps you should raise your warning level a
fair bit. It will help you write better C.

 

[ena8t8si]

Suppose I download a large software package containing, say, several
hundred source files. It might even be in a mix of different
languages. Suppose I only have a strict C90 compiler that doesn't
support "//" comments. If the C code doesn't use "//" comments, I
just do the usual unpack, configure, make, make install (or whatever).
If it does, I can't compile it without editing the source files.
However easy that is for a single file, I'm not likely to take the
time to write something that will do it recursively for the whole
package (unless I *really* need to build and install the package).

Put yourself in the place of the author. If you wanted
to use // comments but still let people use strict C90
compilers, you (a) convert the // comments to /*...*/
comments before publishing, (b) include a small program
(integrated with the makefile that builds the package)
to take out the // comments automatically, or (c) simply
remove the // comments before publishing. If it were me
I'd probably pick (a) or (b), depending on the expected
audience.

On the other hand, if you didn't care about people who
only have strict C90 compilers, you wouldn't do anything,
and they'd be forced to fend for themselves. And that
should be your choice as the author -- they can either
find a way to process source with // comments, or not
use it. But then, how many people don't have an easy
way to compile C with // comments in it?

(As it happens, I've never run into this particular situation myself.)

My point is, if you did run into it, it's only about an
afternoon's worth of work to write a program that solves
the problem. And that's only if you can't set your
compiler to accept // comments.

 

[ena8t8si]

Good point. Perhaps Mr Heathfield should also color-code his
work in HTML so that it will display better in web browsers.
After all, an experienced C programmer like himself could
easily write a filter to remove it come compile time. Or is
that just more anti-internet bias?

One of the sillier analogic arguments I've read.
Haven't you learned not to make arguments that
don't pass the laugh test?

 

[ena8t8si]

(e-mail address removed) said:


Why would I need to write a filter? I don't put // comments into my source
in the first place! The place I encounter // comments most is right here in
comp.lang.c, in code written by people asking for help. If they want help
that badly, they can take the trouble to make their source compilable with
a C90 compiler.

A clever shift in topic. What we _were_ talking about
is how hard would it be to put // comments in your
C source (and still get the ANSI conformance checks
you want). The answer is, not very difficult. But
of course you don't want to admit that, you'd rather
change the topic.

Why would I be biased against something that, for most of us, doesn't even
exist? I am all in favour of C99 becoming as widespread as C90 currently
is. But until it gets to that stage, why would anyone interested in
portability bother to use it?

Of course C99 exists - it's available from ISO. What
you mean is _implementations_ of C99 don't exist (for many
people). If you choose to continue to be one of those
people, fine, but that doesn't mean other people should
want to make the same choice.