The original comment delimiters in C were copied from PL/I: everything
between “/*” and “*/” is a comment, even extending across multiple lines.
Pascal had something similar, only the delimiters were “{” and “}”, or
“(*” and “*)” for compatibility with machines with restricted character
sets.

For some reason, the Ada folks decided block comments were not a good
idea, and so their rule was that anything after “--” up to the end of the
line was a comment. And C++ adopted a similar rule, using “//” as their
to-end-of-line comment marker, though of course they also kept C-style
block comments. Java also keeps both these styles.

Since then, I’ve seen newer programmers gravitate towards the rest-of-line
form in preference to the block form, and I’m not sure why. I’m fond of
writing things like

/*
A very simple HTML/XML entity-escape function--why isn’t this
part of the standard Java API?
*/

which involve less typing than

//
// A very simple HTML/XML entity-escape function--why isn’t this
// part of the standard Java API?
//

Also, the “block” form allows “interspersed” comments, where a short
comment can be put in the middle of a line and followed by more program
text in the rest of the line. For example, as a way of keeping long
argument lists straight:

gdImageCopyResampled
(
/*dst =*/ ResizedFrame,
/*src =*/ Context.StillFrame,
/*dstX =*/ 0,
/*dstY =*/ 0,
/*srcX =*/ 0,
/*srcY =*/ 0,
/*dstW =*/ ResizedFrame->sx,
/*dstH =*/ ResizedFrame->sy,
/*srcW =*/ Context.StillFrame->sx,
/*srcH =*/ Context.StillFrame->sy
);

Do you feel the same?

On 21/03/2024 06:19, Lawrence D'Oliveiro wrote:
> The original comment delimiters in C were copied from PL/I: everything
> between “/*” and “*/” is a comment, even extending across multiple lines.
> Pascal had something similar, only the delimiters were “{” and “}”, or
> “(*” and “*)” for compatibility with machines with restricted character
> sets.
>
> For some reason, the Ada folks decided block comments were not a good
> idea, and so their rule was that anything after “--” up to the end of the
> line was a comment. And C++ adopted a similar rule, using “//” as their
> to-end-of-line comment marker, though of course they also kept C-style
> block comments. Java also keeps both these styles.
>
> Since then, I’ve seen newer programmers gravitate towards the rest-of-line
> form in preference to the block form, and I’m not sure why. I’m fond of
> writing things like
>
> /*
> A very simple HTML/XML entity-escape function--why isn’t this
> part of the standard Java API?
> */
>
> which involve less typing than
>
> //
> // A very simple HTML/XML entity-escape function--why isn’t this
> // part of the standard Java API?
> //
>
> Also, the “block” form allows “interspersed” comments, where a short
> comment can be put in the middle of a line and followed by more program
> text in the rest of the line. For example, as a way of keeping long
> argument lists straight:
>
> gdImageCopyResampled
> (
> /*dst =*/ ResizedFrame,
> /*src =*/ Context.StillFrame,
> /*dstX =*/ 0,
> /*dstY =*/ 0,
> /*srcX =*/ 0,
> /*srcY =*/ 0,
> /*dstW =*/ ResizedFrame->sx,
> /*dstH =*/ ResizedFrame->sy,
> /*srcW =*/ Context.StillFrame->sx,
> /*srcH =*/ Context.StillFrame->sy
> );
>
> Do you feel the same?

No. I can't remember the last time I used /*...*/ comments in C. They're
usually more fiddly to type, and don't nest properly, so that here, if
if you forget */ or don't get it right:

one; /* c1
two; /* c2 */
three; /* c3 */

you get more commented out than you expected.

Relying on possible syntax highlighting of some tools doesn't fix it; it
wouldn't have existed for the first few decades of the language, and my
own editor doesn't do so.

(It does detect // comments which are far easier to support since it
only has to look at the current line; it doesn't need to remember
whether there was an opening /* 5,887 lines previously.)

I see also that 'type' and 'cat' shell commands don't highlight either.

Besides, if you put too much reliance on the editor, then with this example:

> which involve less typing than
>
> //
> // A very simple HTML/XML entity-escape function--why isn’t this
> // part of the standard Java API?
> //

my editor can comment this out this block by pressing the same <insert
line comment> key four times, less typing than using /* */ which can
involve inserting extra lines (which may affect line numbers if that is
important).

If I have a piece of code like this:

s1;
// s2a;
s2b;
s3;

And I need to temporarily comment out the whole block like so:

// s1;
//// s2a;
// s2b;
// s3;

I can do so easily. You can't do that using only /* comments:

s1;
/* s2a; */
s2b;
s3;

because they don't nest.

In short, I no longer bother with block comments in a language; I regard
them as an editor function.

Yes, intra-line comments are sometimes useful, and I have played around
with syntax ideas just for those, for example:

one, \two,\ three

here the 'two,' is commented out. But it just doesn't come up often enough.

On 2024-03-21 06:19:13 +0000, Lawrence D'Oliveiro said:

> The original comment delimiters in C were copied from PL/I: everything
> between “/*” and “*/” is a comment, even extending across multiple lines.
> Pascal had something similar, only the delimiters were “{” and “}”, or
> “(*” and “*)” for compatibility with machines with restricted character
> sets.
>
> For some reason, the Ada folks decided block comments were not a good
> idea, and so their rule was that anything after “--” up to the end of the
> line was a comment. And C++ adopted a similar rule, using “//” as their
> to-end-of-line comment marker, though of course they also kept C-style
> block comments. Java also keeps both these styles.
>
> Since then, I’ve seen newer programmers gravitate towards the rest-of-line
> form in preference to the block form, and I’m not sure why. I’m fond of
> writing things like
>
> /*
> A very simple HTML/XML entity-escape function--why isn’t this
> part of the standard Java API?
> */
>
> which involve less typing than
>
> //
> // A very simple HTML/XML entity-escape function--why isn’t this
> // part of the standard Java API?
> //

But not less than

// A very simple HTML/XML entity-escape function--why isn’t this
// part of the standard Java API?

as the empty lines do not need any comment marks.

> Also, the “block” form allows “interspersed” comments, where a short
> comment can be put in the middle of a line and followed by more program
> text in the rest of the line. For example, as a way of keeping long
> argument lists straight:
>
> gdImageCopyResampled
> (
> /*dst =*/ ResizedFrame,
> /*src =*/ Context.StillFrame,
> /*dstX =*/ 0,
> /*dstY =*/ 0,
> /*srcX =*/ 0,
> /*srcY =*/ 0,
> /*dstW =*/ ResizedFrame->sx,
> /*dstH =*/ ResizedFrame->sy,
> /*srcW =*/ Context.StillFrame->sx,
> /*srcH =*/ Context.StillFrame->sy
> );

I prefer to put the argument names at the end of the line.

> Do you feel the same?

No, I use both kind of comments with languages that permit both.

--
Mikko

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>The original comment delimiters in C were copied from PL/I: everything

Cite?

The answer to the question in the Subject: header is, wait for it,

Both.

When writing C, i use block comments because they're more flexible, and
_only_ block comments for the sake of “picking one and sticking with it”.
The one exception is that i use #if 0 … #endif blocks to “comment out”
blocks of code, since those nest.

--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
The flesh is rotten, but the booze is holding out.

scott@slp53.sl.home (Scott Lurndal) writes:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> The original comment delimiters in C were copied from PL/I: everything
>
> Cite?

Seen in the B language manual:

Comments are delimited as in PL/I by /* and */.

https://www.bell-labs.com/usr/dmr/www/kbman.html

Note that this style of commenting was not present in
B's precursor language, BCPL.

On 21/03/2024 07:19, Lawrence D'Oliveiro wrote:
> The original comment delimiters in C were copied from PL/I: everything
> between “/*” and “*/” is a comment, even extending across multiple lines.
> Pascal had something similar, only the delimiters were “{” and “}”, or
> “(*” and “*)” for compatibility with machines with restricted character
> sets.
>
> For some reason, the Ada folks decided block comments were not a good
> idea, and so their rule was that anything after “--” up to the end of the
> line was a comment. And C++ adopted a similar rule, using “//” as their
> to-end-of-line comment marker, though of course they also kept C-style
> block comments. Java also keeps both these styles.
>
> Since then, I’ve seen newer programmers gravitate towards the rest-of-line
> form in preference to the block form, and I’m not sure why. I’m fond of
> writing things like
>
> /*
> A very simple HTML/XML entity-escape function--why isn’t this
> part of the standard Java API?
> */
>
> which involve less typing than
>
> //
> // A very simple HTML/XML entity-escape function--why isn’t this
> // part of the standard Java API?
> //
>

I use both - block comments when making a comment block, and line
comments when adding comments to the end of a line. That seems pretty
obvious to me.

(Many IDEs will format block comments in a variety of styles according
to user preference - the number of characters typed is rarely an issue.)

> Also, the “block” form allows “interspersed” comments, where a short
> comment can be put in the middle of a line and followed by more program
> text in the rest of the line. For example, as a way of keeping long
> argument lists straight:
>
> gdImageCopyResampled
> (
> /*dst =*/ ResizedFrame,
> /*src =*/ Context.StillFrame,
> /*dstX =*/ 0,
> /*dstY =*/ 0,
> /*srcX =*/ 0,
> /*srcY =*/ 0,
> /*dstW =*/ ResizedFrame->sx,
> /*dstH =*/ ResizedFrame->sy,
> /*srcW =*/ Context.StillFrame->sx,
> /*srcH =*/ Context.StillFrame->sy
> );
>
> Do you feel the same?

I feel that "interspersed comments" are an abomination, and never use
them. Opinions will vary, of course.

On 21/03/2024 15:20, David Brown wrote:
> On 21/03/2024 07:19, Lawrence D'Oliveiro wrote:
>> The original comment delimiters in C were copied from PL/I: everything
>> between “/*” and “*/” is a comment, even extending across multiple lines.
>> Pascal had something similar, only the delimiters were “{” and “}”, or
>> “(*” and “*)” for compatibility with machines with restricted character
>> sets.
>>
>> For some reason, the Ada folks decided block comments were not a good
>> idea, and so their rule was that anything after “--” up to the end of the
>> line was a comment. And C++ adopted a similar rule, using “//” as their
>> to-end-of-line comment marker, though of course they also kept C-style
>> block comments. Java also keeps both these styles.
>>
>> Since then, I’ve seen newer programmers gravitate towards the
>> rest-of-line
>> form in preference to the block form, and I’m not sure why. I’m fond of
>> writing things like
>>
>> /*
>>      A very simple HTML/XML entity-escape function--why isn’t this
>>      part of the standard Java API?
>> */
>>
>> which involve less typing than
>>
>> //
>> //  A very simple HTML/XML entity-escape function--why isn’t this
>> //  part of the standard Java API?
>> //
>>
>
> I use both - block comments when making a comment block, and line
> comments when adding comments to the end of a line.  That seems pretty
> obvious to me.

And sometimes, when it's not a really a comment, but rather a block of
code I don't want right now:

#ifdef 0
....
#endif

In article <86r0g3liii.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> The original comment delimiters in C were copied from PL/I: everything
>>
>> Cite?
>
>Seen in the B language manual:
>
> Comments are delimited as in PL/I by /* and */.
>
>https://www.bell-labs.com/usr/dmr/www/kbman.html
>
>Note that this style of commenting was not present in
>B's precursor language, BCPL.

It would be appropriate to qualify this statement with some kind
of timeframe as BCPL is still used (albeit not widely, I
assume).

The current version of the language includes `/* ... */` comments
as one of two supported forms:
https://www.cl.cam.ac.uk/~mr10/bcplman.pdf

It appears that this was also present in the 1979 version
described in, "BCPL the language and its compiler" by Martin
Richards:
https://ia803107.us.archive.org/16/items/richards1979bcpl/richards1979bcpl.pdf;
see in particular the lexical analyzer fragment starting on line
127 of page 87.

However, I believe this was not the case at the time that B was
defined. At least, it is not in the BCPL definition just a
couple of years earlier, despite several years of experience
with PL/1 by then:
https://www.bell-labs.com/usr/dmr/www/bcpl.pdf
Indeed, Dennis Ritchie suggested that some changes to BCPL were
influences taken from C:
https://www.bell-labs.com/usr/dmr/www/bcpl.html

Certainly, both Multics and CTSS BCPL only understand `// ...`,
and those are likely the compilers that Ken Thompson would have
been most familiar with at the time B was created. E.g.:
https://github.com/dancrossnyc/multics/blob/main/library_dir_dir/system_library_tools/source/bound_bcpl_.s.archive/bcpl_lex1.bcpl#L90

Regarding the original claim, despite OP being a known troll, it
appears to be true. Dennis Ritchie also mentioned it in his C
history paper: https://www.bell-labs.com/usr/dmr/www/chist.html

As far as I know, PL/I was the first language to use `/*` and
`*/` as comment delimeters.

- Dan C.

Lawrence D'Oliveiro wrote:
> The original comment delimiters in C were copied from PL/I: everything
> between “/*” and “*/” is a comment, even extending across multiple lines.
> Pascal had something similar, only the delimiters were “{” and “}”, or
> “(*” and “*)” for compatibility with machines with restricted character
> sets.
>
> For some reason, the Ada folks decided block comments were not a good
> idea, and so their rule was that anything after “--” up to the end of the
> line was a comment. And C++ adopted a similar rule, using “//” as their
> to-end-of-line comment marker, though of course they also kept C-style
> block comments. Java also keeps both these styles.
>
> Since then, I’ve seen newer programmers gravitate towards the rest-of-line
> form in preference to the block form, and I’m not sure why. I’m fond of
> writing things like
>
> /*
> A very simple HTML/XML entity-escape function--why isn’t this
> part of the standard Java API?
> */
>
> which involve less typing than
>
> //
> // A very simple HTML/XML entity-escape function--why isn’t this
> // part of the standard Java API?
> //
>
> Also, the “block” form allows “interspersed” comments, where a short
> comment can be put in the middle of a line and followed by more program
> text in the rest of the line. For example, as a way of keeping long
> argument lists straight:
>
> gdImageCopyResampled
> (
> /*dst =*/ ResizedFrame,
> /*src =*/ Context.StillFrame,
> /*dstX =*/ 0,
> /*dstY =*/ 0,
> /*srcX =*/ 0,
> /*srcY =*/ 0,
> /*dstW =*/ ResizedFrame->sx,
> /*dstH =*/ ResizedFrame->sy,
> /*srcW =*/ Context.StillFrame->sx,
> /*srcH =*/ Context.StillFrame->sy
> );
>
> Do you feel the same?
>

in practice i fint /* */ comments not handy - as bartc noted there is
clear bug thah they dont nest and this is specifically annoying

"i consider this type of comments personally";

the advantage of this above is they are kinda basic i mean c using them
and not using the other type is "thinner", they also felt liek more
physical - and eventually could be build in binary imo by some compiler
switch

i never seen anybody who ises it though, and i noticed that i can use it
but not yet decided - mostly i use // coments becouse i nearly
exclusively use comments to comment out code and in editor i got it
under control+shift+c

Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]
> And sometimes, when it's not a really a comment, but rather a block of
> code I don't want right now:
>
> #ifdef 0
> ...
> #endif

I think you mean "#if 0".

I use that sometimes, but one disadvantage is that if you're viewing the
middle of a very large block of code, it can be hard to tell that it's
been "commented" out.

I have a script that applies "#if 0" and "#endif" to a block of code
*and* prepends "* " to each line in the block.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 21/03/2024 19:23, Keith Thompson wrote:
> Richard Harnden <richard.nospam@gmail.invalid> writes:
> [...]
>> And sometimes, when it's not a really a comment, but rather a block of
>> code I don't want right now:
>>
>> #ifdef 0
>> ...
>> #endif
>
> I think you mean "#if 0".

Yes I did :)

>
> I use that sometimes, but one disadvantage is that if you're viewing the
> middle of a very large block of code, it can be hard to tell that it's
> been "commented" out.
>
> I have a script that applies "#if 0" and "#endif" to a block of code
> *and* prepends "* " to each line in the block.
>

That's a good ideo. Can you share it?

Richard Harnden <richard.nospam@gmail.invalid> writes:
> On 21/03/2024 19:23, Keith Thompson wrote:
>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>> [...]
>>> And sometimes, when it's not a really a comment, but rather a block of
>>> code I don't want right now:
>>>
>>> #ifdef 0
>>> ...
>>> #endif
>> I think you mean "#if 0".
>
> Yes I did :)
>
>> I use that sometimes, but one disadvantage is that if you're viewing
>> the
>> middle of a very large block of code, it can be hard to tell that it's
>> been "commented" out.
>> I have a script that applies "#if 0" and "#endif" to a block of code
>> *and* prepends "* " to each line in the block.
>
> That's a good ideo. Can you share it?

Sure. It's a Perl script called "if0". It tries to deal with
variations in line endings (I sometimes work with code with LF and/or
CRLF line endings) and with tabs vs. spaces as indentation.

I don't have a script that undoes what if0 does. I might write one
one of these days, but usually I can just revert the change in source
control or change it back manually.

Complaints about Perl being write-only will be cheerfully ignored.

```
#!/usr/bin/perl

use strict;
use warnings;

my @lines = <>;
my $newline = "\n";
if (defined $lines[0] and $lines[0] =~ /\r$/) {
$newline = "\r\n";
}

print "#if 0$newline";
foreach my $line (@lines) {
if ($line =~ /^ /) {
$line =~ s/ /*/;
}
elsif ($line =~ /^\r?$/) {
$line =~ s/^/*/;
}
else {
$line =~ s/^/* /;
}
print $line;
} print "#endif /* 0 */$newline";
```

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 21/03/2024 19:48, Keith Thompson wrote:
> Richard Harnden <richard.nospam@gmail.invalid> writes:
>> On 21/03/2024 19:23, Keith Thompson wrote:
>>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>>> [...]
>>>> And sometimes, when it's not a really a comment, but rather a block of
>>>> code I don't want right now:
>>>>
>>>> #ifdef 0
>>>> ...
>>>> #endif
>>> I think you mean "#if 0".
>>
>> Yes I did :)
>>
>>> I use that sometimes, but one disadvantage is that if you're viewing
>>> the
>>> middle of a very large block of code, it can be hard to tell that it's
>>> been "commented" out.
>>> I have a script that applies "#if 0" and "#endif" to a block of code
>>> *and* prepends "* " to each line in the block.
>>
>> That's a good ideo. Can you share it?
>
> Sure. It's a Perl script called "if0". It tries to deal with
> variations in line endings (I sometimes work with code with LF and/or
> CRLF line endings) and with tabs vs. spaces as indentation.
>
> I don't have a script that undoes what if0 does. I might write one
> one of these days, but usually I can just revert the change in source
> control or change it back manually.
>
> Complaints about Perl being write-only will be cheerfully ignored.
>
> ```
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> my @lines = <>;
> my $newline = "\n";
> if (defined $lines[0] and $lines[0] =~ /\r$/) {
> $newline = "\r\n";
> }
>
> print "#if 0$newline";
> foreach my $line (@lines) {
> if ($line =~ /^ /) {
> $line =~ s/ /*/;
> }
> elsif ($line =~ /^\r?$/) {
> $line =~ s/^/*/;
> }
> else {
> $line =~ s/^/* /;
> }
> print $line;
> }
> print "#endif /* 0 */$newline";
> ```
>

Thank you

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Richard Harnden <richard.nospam@gmail.invalid> writes:
>[...]
>> And sometimes, when it's not a really a comment, but rather a block of
>> code I don't want right now:
>>
>> #ifdef 0
>> ...
>> #endif
>
>I think you mean "#if 0".
>
>I use that sometimes, but one disadvantage is that if you're viewing the
>middle of a very large block of code, it can be hard to tell that it's
>been "commented" out.

Often syntax highlighting (e.g. vim) will solve that.

In projects with many fingers in the pie, I generally prefer either a
descriptive (and undefined) macro name or a block comment in
the #if 0 region to indicate exactly _why_ it was not just removed
from the source file entirely.

Makes it easier for whomever is reading and/or maintaining the
code to follow it.

On 2024-03-21, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Richard Harnden <richard.nospam@gmail.invalid> writes:
> [...]
>> And sometimes, when it's not a really a comment, but rather a block of
>> code I don't want right now:
>>
>> #ifdef 0
>> ...
>> #endif
>
> I think you mean "#if 0".
>
> I use that sometimes, but one disadvantage is that if you're viewing the
> middle of a very large block of code, it can be hard to tell that it's
> been "commented" out.

FWIW; Vim colors #if 0 blocks as if they were comments.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-03-21, Scott Lurndal <scott@slp53.sl.home> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>Richard Harnden <richard.nospam@gmail.invalid> writes:
>>[...]
>>> And sometimes, when it's not a really a comment, but rather a block of
>>> code I don't want right now:
>>>
>>> #ifdef 0
>>> ...
>>> #endif
>>
>>I think you mean "#if 0".
>>
>>I use that sometimes, but one disadvantage is that if you're viewing the
>>middle of a very large block of code, it can be hard to tell that it's
>>been "commented" out.
>
> Often syntax highlighting (e.g. vim) will solve that.
>
> In projects with many fingers in the pie, I generally prefer either a
> descriptive (and undefined) macro name or a block comment in
> the #if 0 region to indicate exactly _why_ it was not just removed
> from the source file entirely.
>
> Makes it easier for whomever is reading and/or maintaining the
> code to follow it.

I have a simpler approach: commits which introduced commented-out
code, whether with #if 0, or any other means, shall not be merged.

I don't perpetrate that in my open source projects, and "-1" such
submissions at work.

When someone wants to remove code, I encourage them to actually
delete it. The comment about why it was deleted goes into the
commit log.

Usually people are relieved; deleting it was what they wanted, but they
weren't sure due the code not being their area or whatever.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Thu, 21 Mar 2024 19:46:29 +0100, fir wrote:

> ... mostly i use // coments becouse i nearly
> exclusively use comments to comment out code and in editor i got it
> under control+shift+c

1) You can comment out entire blocks at once with block comments
2) This is why we have version control; just delete the unneeded block,
since you can get it back from your commit history if you change your mind
later anyway.

On Thu, 21 Mar 2024 13:37:57 +0200, Mikko wrote:

> On 2024-03-21 06:19:13 +0000, Lawrence D'Oliveiro said:
>
>> gdImageCopyResampled
>> (
>> /*dst =*/ ResizedFrame,
>> /*src =*/ Context.StillFrame, /*dstX =*/ 0,
>> /*dstY =*/ 0,
>> /*srcX =*/ 0,
>> /*srcY =*/ 0,
>> /*dstW =*/ ResizedFrame->sx, /*dstH =*/ ResizedFrame->sy,
>> /*srcW =*/ Context.StillFrame->sx,
>> /*srcH =*/ Context.StillFrame->sy
>> );
>
> I prefer to put the argument names at the end of the line.

But putting them in front of the values looks more like the syntax in
languages (like Ada and Python) that do allow specification of argument
keywords.

And maybe, in future, if it becomes valid in C (or some successor), then
updating the code should be as simple as removing the comment symbols.

On Thu, 21 Mar 2024 12:48:53 -0700, Keith Thompson wrote:

> It's a Perl script ...

Shame. I was hoping for something in, say, Emacs Lisp, that can be invoked
from directly within the editor, operating on a selected region within the
buffer, and bound to a keystroke.

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-03-21, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>> [...]
>>> And sometimes, when it's not a really a comment, but rather a block of
>>> code I don't want right now:
>>>
>>> #ifdef 0
>>> ...
>>> #endif
>>
>> I think you mean "#if 0".
>>
>> I use that sometimes, but one disadvantage is that if you're viewing the
>> middle of a very large block of code, it can be hard to tell that it's
>> been "commented" out.
>
> FWIW; Vim colors #if 0 blocks as if they were comments.

Sure, but I don't always view code in a way that allows for
language-specific highlighting. (In fact I rarely do so, and I'm not
willing to assume that everyone else always does so.)

I developed my habits when syntax highlighting wasn't an option.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 21 Mar 2024 12:48:53 -0700, Keith Thompson wrote:
>> It's a Perl script ...
>
> Shame. I was hoping for something in, say, Emacs Lisp, that can be invoked
> from directly within the editor, operating on a selected region within the
> buffer, and bound to a keystroke.

Feel free to write it. (And an Emacs Lisp function doesn't help me in vim.)

Perhaps I should have mentioned that the Perl script I posted reads from
stdin and writes to stdout. It can also read from one or more files
named on its command line.

It slurps all its input into memory. I could have written it to stream
stdin to stdout, which could work better for large inputs, but the
current version works well enough for me.

#if 0
* Meanwhile, Emacs can invoke an external command on a region of text, and
* you can bind that to a keystroke if you like. I used it on this paragraph.
#endif /* 0 */

"shell-command-on-region" is bound to "M-|" (Alt-| or Esc |).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 21/03/2024 22:16, Lawrence D'Oliveiro wrote:
> On Thu, 21 Mar 2024 13:37:57 +0200, Mikko wrote:
>
>> On 2024-03-21 06:19:13 +0000, Lawrence D'Oliveiro said:
>>
>>> gdImageCopyResampled
>>> (
>>> /*dst =*/ ResizedFrame,
>>> /*src =*/ Context.StillFrame, /*dstX =*/ 0,
>>> /*dstY =*/ 0,
>>> /*srcX =*/ 0,
>>> /*srcY =*/ 0,
>>> /*dstW =*/ ResizedFrame->sx, /*dstH =*/ ResizedFrame->sy,
>>> /*srcW =*/ Context.StillFrame->sx,
>>> /*srcH =*/ Context.StillFrame->sy
>>> );
>>
>> I prefer to put the argument names at the end of the line.
>
> But putting them in front of the values looks more like the syntax in
> languages (like Ada and Python) that do allow specification of argument
> keywords.
>

Why would you want your C code to look like Python? That's as silly as
wanting your Python code to look like C code. The languages are
significantly different - each with their strengths and weaknesses, and
each suitable for quite different kinds of programming tasks.

I can appreciate wanting to document what the parameters are in a
function that takes far too many parameters. I don't see any benefit in
doing so in a way that looks vaguely like an entirely different
programming language.

gdImageCopyResampled
( ResizedFrame, // destination frame
Context.StillFrame, // source frame
0, 0, // destination x, y
0, 0, // source x, y
ResizedFrame->sx, // frame sizes
ResizedFrame->sy,
Context.StillFrame->sx,
Context.StillFrame->sy
);

That is simpler and more informative than your style (IMHO of course).

> And maybe, in future, if it becomes valid in C (or some successor), then
> updating the code should be as simple as removing the comment symbols.

I am a fan of being able to name parameters in languages that allow it.
I am quite confident that this will never come to C. It /might/ make it
into C++, but as people have been writing proposals to do so for 20
years at least, I am not holding my breath.

In the meantime, you can use structs with parameters and use designated
initialisers and compound literals to get a similar effect but with a
heavier and less flexible syntax. Or you can use specific types for
each parameter, along with macros (or constructors in C++), to ensure
that you can't get the parameters mixed up. Again, it's more boiler
plate and a heavier syntax than named parameters would be.

On 21/03/2024 17:32, Richard Harnden wrote:
> On 21/03/2024 15:20, David Brown wrote:
>> On 21/03/2024 07:19, Lawrence D'Oliveiro wrote:
>>> The original comment delimiters in C were copied from PL/I: everything
>>> between “/*” and “*/” is a comment, even extending across multiple
>>> lines.
>>> Pascal had something similar, only the delimiters were “{” and “}”, or
>>> “(*” and “*)” for compatibility with machines with restricted character
>>> sets.
>>>
>>> For some reason, the Ada folks decided block comments were not a good
>>> idea, and so their rule was that anything after “--” up to the end of
>>> the
>>> line was a comment. And C++ adopted a similar rule, using “//” as their
>>> to-end-of-line comment marker, though of course they also kept C-style
>>> block comments. Java also keeps both these styles.
>>>
>>> Since then, I’ve seen newer programmers gravitate towards the
>>> rest-of-line
>>> form in preference to the block form, and I’m not sure why. I’m fond of
>>> writing things like
>>>
>>> /*
>>>      A very simple HTML/XML entity-escape function--why isn’t this
>>>      part of the standard Java API?
>>> */
>>>
>>> which involve less typing than
>>>
>>> //
>>> //  A very simple HTML/XML entity-escape function--why isn’t this
>>> //  part of the standard Java API?
>>> //
>>>
>>
>> I use both - block comments when making a comment block, and line
>> comments when adding comments to the end of a line.  That seems pretty
>> obvious to me.
>
> And sometimes, when it's not a really a comment, but rather a block of
> code I don't want right now:
>
> #ifdef 0

"#if 0", presumably.

> ...
> #endif
>

Yes, I do that too. But if it is more than just a fairly trivial amount
of code, and not just for quite tests during development, then I hugely
prefer to give the block a name:

// Explanation of EnableExtraChecks ...
#define EnableExtraChecks 1

....

#if EnableExtraChecks
....
#endif // #if EnableExtraChecks

Depending on the circumstances, the guard macro definition might be at
the start of the file, or it might be just before the commented-out
block. But even in the later case, giving it a name like this makes it
easier to match up when the #endif (and perhaps #else) has a comment.
It also makes it easier to get right if there are several blocks that
get commented out, whether they use the same or different guards.

Note that some coding standards (such as MISRA) do not allow this
technique, because it can be hard (without a good highlighting editor or
IDE) to see if code is active or disabled.

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <86r0g3liii.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> The original comment delimiters in C were copied from PL/I: everything
>>>
>>> Cite?
>>
>> Seen in the B language manual:
>>
>> Comments are delimited as in PL/I by /* and */.
>>
>> https://www.bell-labs.com/usr/dmr/www/kbman.html
>>
>> Note that this style of commenting was not present in
>> B's precursor language, BCPL.
>
> It would be appropriate to qualify this statement with some kind
> of timeframe as BCPL is still used (albeit not widely, I assume).

The PL/I style of commenting was not present in BCPL at the time B
was being defined. My source is MIT Project Mac Memorandum-M-352
dated July 21, 1967. I expect this document can be found on the
net but I don't have a link for it.