Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!olivea!orc!inews!hopi!bhoughto
From: bhoughto@hopi.intel.com (Blair P. Houghton)
Newsgroups: comp.std.c
Subject: Re: comment style
Message-ID: <1640@inews.intel.com>
Date: 7 Jan 91 17:21:36 GMT
References: <613@caslon.cs.arizona.edu> <1050:Jan701:40:4791@kramden.acf.nyu.edu> <616@caslon.cs.arizona.edu>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 61

In article <616@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes:
>In article <1050:Jan701:40:4791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>|In article <613@caslon.cs.arizona.edu| dave@cs.arizona.edu (Dave P. Schaumann) writes:
>|| I see no compelling reason to have //, and have heard
>|| no argument for // that doesn't boil down to 'I like it that way better'.

The political scientists can prove to you why it ever will be thus.

>|4. It is always obvious, to both human eye and mechanical parser, where
>|a // comment ends (viz., the end of the line). It is not so trivial to
>|locate the next */.
>
>My editor has a 'search for text' function.  Doesn't yours?

Many editors use softlines; i.e., there is no end-of-line in
the file, though your screen and eyes see one.  With a
pre- and post-delimiting comment format these editors are not
obsolesced (lame reason).  Recall that the ends of lines in
the translation units are a user convenience only, and the
compiler is allowed to be able to treat the entire program as
one long line (cf. the 509-character minimum-maximum limit),
if it so wishes.  Pathological storage schemes may find this
necessary, obviating any construct requiring the newline
glyph in the translation unit.  I.e., it is to lose-lose.

>|6. An end-of-line comment mechanism can double as the line continuation
>|mechanism, as in TeX. This is a beautifully simple way to kill two birds
>|with one stone; it cuts the relevant sections of the standard in half.
>
>Unfortunately, I don't know what you are referring to here, so I can't comment.

Likewise.  TeX ignores newlines, unless you tell it not to,
as for example by placing a comment there, which it then ignores.

>|7. There's always lots of fuss over matched comments as in C, while
>|there's never a fuss over per-line comments as in the shells or TeX.
>
>I agree that it could be easy to misplace a */ when entering code.  However, as
>another post points out, // comments can have there own pitfalls when the line
>ends with a '\'.

Shells and TeX[*] have very important reasons for making
newlines significant; although TeX ignores them and sh(1)
can be made to run without them, in which case it would be
REALLY NICE to have a double-ended, comment-delimiting
scheme for them both.

>|There. Now you've heard several arguments for // that don't boil down to
>|``I like it that way better.'' You may not consider them compelling but
>|you can't say they don't exist.

Like I said:  the former case the political scientists could
refute.  The latter, you win.

				--Blair
				  "//let's hope you never get stuck\n\
				   // trying to look too closely\n\
				   // at something like this...\n"

[*] Not to be confused with Kraft Shells and Cheese,
which is much more tasty than anything under Unix... :-)