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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Brown wrote:

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.

Wrong. C is the only general-purpose language worth using for anything.



--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site
You miss all the shoes you don't take!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/21/24 15: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".

I'm sure he did. However, I'd like to mention that I have occasionally
used #ifdef with a macro name that I haven't #defined, and have no plans
to #define, but which describes the reason why I'm commenting this
section out. This is purely to document my reason, but should I ever
change my mind, I can simply #define the corresponding macro.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <86edc2l7lw.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

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.

Correct.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 22 Mar 2024 12:20:16 -0400, James Kuyper wrote:

... I have occasionally
used #ifdef with a macro name that I haven't #defined, and have no plans
to #define, but which describes the reason why I'm commenting this
section out.

I’ve seen that. E.g.

#ifdef USE_STUPID_CODE
... do things one way ...
#else
... do things the better way ...
#endif

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 22 Mar 2024 10:02:47 +0100, David Brown wrote:

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.

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.

Why would you want your C code to look like Python?

Is “Python” some kind of trigger word with you? Soon as you see that, a switch clicks off in your brain, and you are incapable of focussing on
anything else that was said?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 22 Mar 2024 21:15:45 -0700, Chris M. Thomasson wrote:

On 3/22/2024 7:58 PM, Lawrence D'Oliveiro wrote:

On Fri, 22 Mar 2024 10:02:47 +0100, David Brown wrote:

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

Why would you want your C code to look like Python?

Is “Python” some kind of trigger word with you? Soon as you see that, a >> switch clicks off in your brain, and you are incapable of focussing on
anything else that was said?

Notice the name of the group?

Notice the code I posted?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 23/03/2024 03:58, Lawrence D'Oliveiro wrote:

On Fri, 22 Mar 2024 10:02:47 +0100, David Brown wrote:

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.

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.

Why would you want your C code to look like Python?

Is “Python” some kind of trigger word with you? Soon as you see that, a switch clicks off in your brain, and you are incapable of focussing on anything else that was said?

No, I am quite happy with Python, and use it regularly. It is simply
that Python and C are very different languages, and I see no benefit in
trying to make one look like the other. (And I talked more about Python
than Ada because my knowledge of Ada is a lot more limited compared to
my knowledge and experience with Python - and I expect that pattern is
common amongst other people in c.l.c.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/21/2024 2:19 AM, Lawrence D'Oliveiro wrote:

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

Get yourself some Notepad++.

Highlight a block of comments and hit Ctrl + Q.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-03-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

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?

A normal person won't compulsively comment very function argument,
but if they had to do it, here is what it might look like:

gdImageCopyResampled(ResizedFrame, // dst
Context.StillFrame, // src
0, 0, 0, 0, // {dst,src}{X,Y}
ResizedFrame->sx, // dstW
ResizedFrame->sy, // dstH
Context.StillFrame->sx, // srcW
Context.StillFrame->sy); // srcH

gdImageCopyResampled(ResizedFrame, /* dst */
Context.StillFrame, /* src */
0, 0, 0, 0, /* {dst,src}{X,Y} */
ResizedFrame->sx, /* dstW */
ResizedFrame->sy, /* dstH */
Context.StillFrame->sx, /* srcW */
Context.StillFrame->sy); /* srcH */

Using either kind of comment, it goes at the end of the line, with a
decent amount of space. The reader of the code who doesn't find
the comments helpful can easily ignore them.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lowell Gilbert <lgusenet@be-well.ilk.org> writes:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

A normal person won't compulsively comment very function argument,

Well, they might if they're generating documentation from the
comments.

The discussion was about function arguments in a call. Documentation
would, presumably, be generated from comments on (formal) parameters in
a function declaration.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Kaz Kylheku <643-408-1753@kylheku.com> writes:

A normal person won't compulsively comment very function argument,

Well, they might if they're generating documentation from the comments.
Even then, it would usually only be a concern for API-type functions,
which means a fairly small share of a typical codebase.

The original post is kind of weird, though, in that its author's idea of
what it easy to type seems to be based on writing code out on a
typewriter. Maybe a Teletype without a C-savvy editor program.

Be well.
--
Lowell Gilbert, embedded/networking software engineer
http://be-well.ilk.org/~lowell/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-04-23, Lowell Gilbert <lgusenet@be-well.ilk.org> wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

A normal person won't compulsively comment very function argument,

Well, they might if they're generating documentation from the comments.
Even then, it would usually only be a concern for API-type functions,
which means a fairly small share of a typical codebase.

I think here you're thinking more of formal parameters, rather than
argument expressions in calls.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

Lowell Gilbert <lgusenet@be-well.ilk.org> writes:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

A normal person won't compulsively comment very function argument,

Well, they might if they're generating documentation from the
comments.

The discussion was about function arguments in a call. Documentation
would, presumably, be generated from comments on (formal) parameters in
a function declaration.

Fair enough. I drifted too far.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 23 Apr 2024 16:13:34 -0400, DFS wrote:

On 3/21/2024 2:19 AM, Lawrence D'Oliveiro wrote:

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

Get yourself some Notepad++.

Highlight a block of comments and hit Ctrl + Q.

Get an inferior piece of software, available only on an inferior platform,
just to turn a comment style that I like into one I don’t like?

What next: you want me to give up my car for a rickshaw, and move to a
village on top of a cliff?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

DFS wrote:

Get yourself some Notepad++.

Not everybody can afford a machine powerful enough for a fancy text editor
like that.



--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site
“You know what that means.” “No i don't.”

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24.04.24 14:36, Blue-Maned_Hawk wrote:

DFS wrote:

Get yourself some Notepad++.

Not everybody can afford a machine powerful enough for a fancy text editor like that.

BULSHIT.
I run notepad++ on a 20 year old xp pro machine, and never
had a problem.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sjouke Burry wrote:

On 24.04.24 14:36, Blue-Maned_Hawk wrote:

DFS wrote:

Get yourself some Notepad++.

Not everybody can afford a machine powerful enough for a fancy text
editor like that.

BULSHIT.
I run notepad++ on a 20 year old xp pro machine, and never had a
problem.

I don't see how that refutes my claim instead of substantiating it.



--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site
Bribe^WLoan^WCompensation

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/24/2024 8:36 AM, Blue-Maned_Troll wrote:

DFS wrote:

Get yourself some Notepad++.

Not everybody can afford a machine powerful enough for a fancy text editor like that.

Notepad++ will run on $25 dumpster hardware.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

DFS wrote:

On 4/24/2024 8:36 AM, Blue-Maned_Troll wrote:

That's an unsubstantiated claim.

DFS wrote:

Get yourself some Notepad++.

Not everybody can afford a machine powerful enough for a fancy text
editor like that.

Notepad++ will run on $25 dumpster hardware.

So what? Not everybody can afford a machine that powerful.



--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site
I wish i had a brain. I also wish i had a crunch bar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/25/2024 6:10 PM, Blue-Maned_Troll trolled again:

DFS wrote:

On 4/24/2024 8:36 AM, Blue-Maned_Troll wrote:

That's an unsubstantiated claim.

That's a fact.

DFS wrote:

Get yourself some Notepad++.

Not everybody can afford a machine powerful enough for a fancy text
editor like that.

Notepad++ will run on $25 dumpster hardware.

So what? Not everybody can afford a machine that powerful.

Not the crowd you run with anyway.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Kaz Kylheku <433-929-6894@kylheku.com> wrote:

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.

Yes!! Every time a dev checks in dead code, $DEITY kills a small furry
creature out of spite.

Maybe it was appropriate 40 years ago before we had version control
systems, but we do now, and code deleted that needed to stay can easily
be brought back from the void. (I just had to do that in my day job, an "unused" line which the IDE flagged actually was important and removing
it caused a runtime error. It was a 5 second fix when I could just pull
up the change details and pull the line back in.)

--
Paul.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

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

For me, it's block form for larger blocks of comment (descriptive stuff, really, where a lot of info is needed).

Shorter comments use the rest-of-line form.

Since most of the comments I put in code are short (usually just to
describe what the next section does, if necessary, and typically are a
single line) they end up being mostly rest-of-line.

At work, with the autodoc system we use in Visual Studio, it requires
comment blocks which have 3 slashes ( /// ). Not a fan, but no choice
there either.

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

Ewww, no. That's a perfect case for end-of-line rest-of-line comments
after each line. Or refactoring the function signature somehow if
possible because that's a lot of parameters. Interspersed is just
messy-looking IMO. :)

One use for this though: if I'm making temporary changes to test
something out, I'll often comment out a bit of a line using /* .. */ but it's solely for test purposes, and never ends up being committed.

Also some of this becomes moot anyway if a project has style guidelines,
not to mention automation in some editors (it's only more typing if the
editor doesn't autocomplete it for you).

--
Paul.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.
You can sort of already do it in C by using designated initializers and macros #define foo(A, B, C, ...) do{\
stuct technical technical={\
var1=default1,\
var2=default2,\
var3=default3 __VA_OPT__(,)\
__VA_ARGS__\
}\
actual_foo(A, B, C, technical.var1, technical.var2, technical.var3)\ }while(0)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02/07/2024 20:39, Blue-Maned_Hawk wrote:

I searched around a bit, and it seems like a more common way to implement named arguments in C is with a pattern like this:

#define f(...) f_impl((struct f_struct){__VA_ARGS__})
void f_impl(struct f_struct { int i, j; char * k; double l, m, n; } f_params)
{
/* actual code */
}

int main(void)
{
f(.i = 0, .j = 2, .l = 2.5, .k = "foo", .n = 4.2, .m = 2.5);
}

That's the kind of thing Bonita would write.
Horrible.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02/07/2024 20:39, Blue-Maned_Hawk wrote:

I searched around a bit, and it seems like a more common way to implement named arguments in C is with a pattern like this:

#define f(...) f_impl((struct f_struct){__VA_ARGS__})
void f_impl(struct f_struct { int i, j; char * k; double l, m, n; } f_params)
{
/* actual code */

You missed out accesses to the parameters which would look like
f_params.i and f_params.m.

}

int main(void)
{
f(.i = 0, .j = 2, .l = 2.5, .k = "foo", .n = 4.2, .m = 2.5);
}

This addresses a small part of it. Named parameters allow arguments to
be omitted, and that requires also default values to be defined.

You can make ever more complex schemes to emulate them in C, but the boilerplate will just increase.

But at least, this allows parameters with the same type to be declared as:

double l, m, n

instead of:

double l, double m, double n

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I searched around a bit, and it seems like a more common way to implement
named arguments in C is with a pattern like this:

#define f(...) f_impl((struct f_struct){__VA_ARGS__})
void f_impl(struct f_struct { int i, j; char * k; double l, m, n; }
f_params)
{
/* actual code */
}

int main(void)
{
f(.i = 0, .j = 2, .l = 2.5, .k = "foo", .n = 4.2, .m = 2.5);
}

--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site
Here are some house rules that we highly recommend you don't use.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2 Jul 2024 21:53:48 +0500, Ivan Farlenkov wrote:

You can sort of already do it in C by using designated initializers and macros

There is simply no good way of doing it without having it as a
built-in language feature.

When I was first learning about C (back in the 1980s), it was apparent
that it was a poor fit for my favourite OS of the time, DEC’s VMS.
Consider the ominibus non-file-structured I/O function call, SYS$QIO <https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04623201>
(page 282 onwards). The C prototype looks like this:

int sys$qio
(
unsigned int efn,
unsigned short int chan,
unsigned int func,
struct _iosb *iosb,
void (*astadr)(__unknown_params),
__int64 astprm,
void *p1,
__int64 p2,
__int64 p3,
__int64 p4,
__int64 p5,
__int64 p6
);

“func” is, or used to be, 10 bits of function code (e.g. read, write)
plus 6 bits of function modifier (e.g. do read with timeout). The
generic arguments p1-p6 have function-dependent meanings, though p1 is
usually a buffer address.

This call is asynchronous, and offers 3 different ways of notifying
I/O completion: by setting an “event flag” (the number of which is specified in the “efn” arg), by filling in an “I/O status block” (the address of which can be passed in the “iosb” arg), and by invoking an “AST” (“Asynchronous System Trap”) completion routine, the address of which can be passed in the “astadr” arg (plus an extra arg for caller
use in “astprm” that could be used, for example, to identify the
context of the I/O request in question).

The only function I can remember that used all 6 function-specific
arguments was the “read-with-prompt” function of the terminal driver,
with the timeout option. In this call, we had
p1 -- the buffer in which to return the user input
p2 -- the length of the input buffer
p3 -- the read timeout in seconds
p4 -- the read termination character mask
p5 -- the address of the prompt string to display
p6 -- the length of the prompt string

What was good about read-with-prompt, versus doing your own output of
the prompt string followed by a simple read? It could automatically
redisplay your prompt string in any situation where the screen got
messed up and needed refreshing (e.g. after a system broadcast message
was displayed).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Harnden wrote:

On 02/07/2024 20:39, Blue-Maned_Hawk wrote:

I searched around a bit, and it seems like a more common way to
implement named arguments in C is with a pattern like this:

#define f(...) f_impl((struct f_struct){__VA_ARGS__})
void f_impl(struct f_struct { int i, j; char * k; double l, m, n; }
f_params)
{
/* actual code */
}

int main(void)
{
f(.i = 0, .j = 2, .l = 2.5, .k = "foo", .n = 4.2, .m = 2.5);
}

That's the kind of thing Bonita would write.
Horrible.

I assure you that i can write much worse code. What do you say makes this
is horrible?



--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site
It's like this other thing, except awful!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart wrote:

On 02/07/2024 20:39, Blue-Maned_Hawk wrote:

I searched around a bit, and it seems like a more common way to
implement named arguments in C is with a pattern like this:

#define f(...) f_impl((struct f_struct){__VA_ARGS__})
void f_impl(struct f_struct { int i, j; char * k; double l, m, n; }
f_params)
{
/* actual code */

You missed out accesses to the parameters which would look like
f_params.i and f_params.m.

Apologies—i assumed that it woudl be obvious that that's how it would be done.

}

int main(void)
{
f(.i = 0, .j = 2, .l = 2.5, .k = "foo", .n = 4.2, .m = 2.5);
}

This addresses a small part of it. Named parameters allow arguments to
be omitted, and that requires also default values to be defined.

I think there's a difference of nomenclature here, because i would
consider named parameters to _only_ imply the ability to name parameters,
and not necessarily imply parameter omission.

Nevertheless, while searching around, i _did_ see people describe a way to assign default parameter values with a feature that i can confidently say
i've never seen used anywhere else: the ability to specify designated initializers twice and have the latter override the first.

You can make ever more complex schemes to emulate them in C, but the boilerplate will just increase.

On the other hand, some boilerplate could be alleviated: we could get a
result of

#define f(...) DEF(f, .i = 1, .j = 2, .k = "blah", __VA_ARGS__)

void DEC(f, int i, j; char * k; double l, m, n;)
{
/* actual code */
}

through the macros

#define DEF(name, ...) name##_impl((struct name##_struct){__VA_ARGS__})

#define DEC(name, ...) name##_impl(struct name##_struct {__VA_ARGS__} name##_params)

which, while not perfect (i'm not a fan of the __VA_ARGS__ repetition
necessary in DEF), do make things better and probably a little less error- prone.

(Apparently, the P99 preprocessor library also has some macros in it to
allow for default subroutine arguments. I have done absolutely no
research into how these work or whether they're any good.)

But at least, this allows parameters with the same type to be declared
as:

double l, m, n

instead of:

double l, double m, double n

I'm going to go out on a limb here and assume that the former form would
have caused some sort of grammatical ambiguity/complexity issues when prestandard declarations were still in the standard, but _might_ be implementable nowadays now that they've been removed from the standard.



--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site
It would be disasterous!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03/07/2024 21:42, Blue-Maned_Hawk wrote:

bart wrote:

On 02/07/2024 20:39, Blue-Maned_Hawk wrote:

I searched around a bit, and it seems like a more common way to
implement named arguments in C is with a pattern like this:

#define f(...) f_impl((struct f_struct){__VA_ARGS__})
void f_impl(struct f_struct { int i, j; char * k; double l, m, n; }
f_params)
{
/* actual code */

You missed out accesses to the parameters which would look like
f_params.i and f_params.m.

Apologies—i assumed that it woudl be obvious that that's how it would be done.

Part of the reason for using the feature is for simpler, clearer code.
But such solutions have costs in the form of extra syntax, extra clutter
that can obscure what you're trying to do.

So I think it was important to show that reflected in your example.

A built-in named-argument feature would not require any changes to the
body of a function. The only difference might be in specifying default
values for optional arguments.

On the other hand, some boilerplate could be alleviated: we could get a result of

#define f(...) DEF(f, .i = 1, .j = 2, .k = "blah", __VA_ARGS__)

void DEC(f, int i, j; char * k; double l, m, n;)
{
/* actual code */
}

through the macros

#define DEF(name, ...) name##_impl((struct name##_struct){__VA_ARGS__})

#define DEC(name, ...) name##_impl(struct name##_struct {__VA_ARGS__} name##_params)

which, while not perfect (i'm not a fan of the __VA_ARGS__ repetition necessary in DEF), do make things better and probably a little less error- prone.

(Apparently, the P99 preprocessor library also has some macros in it to
allow for default subroutine arguments. I have done absolutely no
research into how these work or whether they're any good.)

This is all very ingenious, but I doubt the results are worth it in
practice. What short of error messages are you likely to get for a typo
for example?

My language, which has the feature, would define the same function like
this:

proc f(int i=1, j=2, ichar k="blah", real l, m, n) =
....
end

It might be called like this:

f(l:10, m:20, n:30)

(The floats are the only ones that can't be omitted.)


It really needs language support. That has been done in C for designated initialisers; named args are a similar feature, easier to implement
(they can only be one level deep for example) and IMO far more useful.

Although there are a few extra problems with C because the extra info
needed (parameter names and default values) can appear in both the
definition, and any number of prototype declarations, which cannot in
conflict.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-04, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

bart <bc@freeuk.com> writes:
[...]

It really needs language support. That has been done in C for
designated initialisers; named args are a similar feature, easier to
implement (they can only be one level deep for example) and IMO far
more useful.

Although there are a few extra problems with C because the extra info
needed (parameter names and default values) can appear in both the
definition, and any number of prototype declarations, which cannot in
conflict.

As I recall, we had this discussion here a while ago. The fact that C
allows parameter names for a function definition to differ from those in corresponding declarations is a bit inconvenient. But what I recall suggesting at the time is that the parameter names in a call need to be consistent with the names in the visible declaration.

void foo(int x, int y) {
// ...
}

void foo(int xx, int yy);

foo(xx: 10, yy: 20);

void (*pfoo)(int y, int x) = foo;

pfoo(xx: 10, yy: 20); // oops, arguments are silently reversed

Before we have named arguments, we have to somehow make name part of the
type, so that the above pointer initialization violates a constraint.

Problem:

void foo(int, int);

void (*foo1)(int y, int x) = foo;

void (*foo2)(int x, int y) = foo;

The crux is that parameters/arguments which are /simultaneously/ named /and/ positional are a bad idea.

Keyword parmeters should be a separate new category, specially
declared, and understood not to be ordered. There should be no way
to pass by-order arguments to keyword parameters.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03/07/2024 21:16, Blue-Maned_Hawk wrote:

Richard Harnden wrote:

On 02/07/2024 20:39, Blue-Maned_Hawk wrote:

I searched around a bit, and it seems like a more common way to
implement named arguments in C is with a pattern like this:

#define f(...) f_impl((struct f_struct){__VA_ARGS__})
void f_impl(struct f_struct { int i, j; char * k; double l, m, n; }
f_params)
{
/* actual code */
}

int main(void)
{
f(.i = 0, .j = 2, .l = 2.5, .k = "foo", .n = 4.2, .m = 2.5);
}

That's the kind of thing Bonita would write.
Horrible.

I assure you that i can write much worse code. What do you say makes this
is horrible?

It just doesn't feel like how C ought to be, not to me anyway.

If you have named parameters, then you have to allow default values.
Then you have function overloading.

I mostly try to avoid function-like macros - this would force them to be everywhere - and the definition would be far away from the call.

I agree with Bart downthread ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02/07/2024 21:50, bart wrote:

On 02/07/2024 20:39, Blue-Maned_Hawk wrote:

int main(void)
{
    f(.i = 0, .j = 2, .l = 2.5, .k = "foo", .n = 4.2, .m = 2.5);
}

This addresses a small part of it. Named parameters allow arguments to
be omitted, and that requires also default values to be defined.

It actually allows parameters to be omitted, since one can omit struct
members. And it also gets default values for these, but it's a fixed
one, zero. So, that's limited. But possibly useful.

Not that I find obfuscating basic C syntax, like argument passing,
behind a macro a good idea. But hey.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-04, Richard Harnden <richard.nospam@gmail.invalid> wrote:

On 03/07/2024 21:16, Blue-Maned_Hawk wrote:

Richard Harnden wrote:

On 02/07/2024 20:39, Blue-Maned_Hawk wrote:

I searched around a bit, and it seems like a more common way to
implement named arguments in C is with a pattern like this:

#define f(...) f_impl((struct f_struct){__VA_ARGS__})
void f_impl(struct f_struct { int i, j; char * k; double l, m, n; }
f_params)
{
/* actual code */
}

int main(void)
{
f(.i = 0, .j = 2, .l = 2.5, .k = "foo", .n = 4.2, .m = 2.5);
}

That's the kind of thing Bonita would write.
Horrible.

I assure you that i can write much worse code. What do you say makes this >> is horrible?

It just doesn't feel like how C ought to be, not to me anyway.

If you have named parameters, then you have to allow default values.
Then you have function overloading.

Whether or not a parameter is required or optional is orthogonal as to
whether or not it is a keyword/named parameter.

Some languages have fixed positional parameters accompanied by an
optional bag of keywords. The keywords may be numerous and so need to be treated as optional with defaults.

The design of those languages is not the only possible point in the
design space.

We can conceive of keyword parameters being all required.


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 4 Jul 2024 13:12:18 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:

Am 02.07.2024 um 18:53 schrieb Ivan Farlenkov:

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.

You can sort of already do it in C by using designated initializers
and macros
#define foo(A, B, C, ...) do{\
����stuct technical technical={\
������� var1=default1,\
������� var2=default2,\
������� var3=default3 __VA_OPT__(,)\
������� __VA_ARGS__\
����}\
����actual_foo(A, B, C, technical.var1, technical.var2,
technical.var3)\ }while(0)

What an anquated language that this needs macros.

I don't suppose that somebody likes this macro stuff or takes it
seriously. It's just a PoC.
But at least we can imagine how named call arguments can be added to "antiquated language" if The Committee decides to do so. It would not
be easy, but clash with other language features is avoidable.
Not so with "modern language" that your like. For "modern language" the
clash with other [mis]features will be unavoidable and fatal.

[O.T.]
If I am not mistaken "modern language" is so twisted that it can't even
have proper designated initializers for struct (proper = arbitrary
order). I don't know what is the reason for that, but the reason exists.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04/07/2024 12:12, Bonita Montero wrote:

Am 02.07.2024 um 18:53 schrieb Ivan Farlenkov:

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.

You can sort of already do it in C by using designated initializers
and macros
#define foo(A, B, C, ...) do{\
     stuct technical technical={\
         var1=default1,\
         var2=default2,\
         var3=default3 __VA_OPT__(,)\
         __VA_ARGS__\
     }\
     actual_foo(A, B, C, technical.var1, technical.var2, technical.var3)\
}while(0)

What an anquated language that this needs macros.

How do you do it in C++?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c++

On Thu, 4 Jul 2024 15:02:49 +0300
Michael S <already5chosen@yahoo.com> wrote:

On Thu, 4 Jul 2024 13:12:18 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:

Am 02.07.2024 um 18:53 schrieb Ivan Farlenkov:

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.

You can sort of already do it in C by using designated
initializers and macros
#define foo(A, B, C, ...) do{\
����stuct technical technical={\
������� var1=default1,\
������� var2=default2,\
������� var3=default3 __VA_OPT__(,)\
������� __VA_ARGS__\
����}\
����actual_foo(A, B, C, technical.var1, technical.var2,
technical.var3)\ }while(0)

What an anquated language that this needs macros.

I don't suppose that somebody likes this macro stuff or takes it
seriously. It's just a PoC.
But at least we can imagine how named call arguments can be added to "antiquated language" if The Committee decides to do so. It would not
be easy, but clash with other language features is avoidable.
Not so with "modern language" that your like. For "modern language"
the clash with other [mis]features will be unavoidable and fatal.

On the second thought.
I can think about the way of adding named arguments to "modern
language". But the way I am thinking of is an equivalent of creation of
new declaration/call syntax in parallel with existing syntax. It would
require two new keywords. It will make every declaration and call a
word longer.
None of that is strictly required for addition of named arguments to "antiquated language" although addition of new keyword for declaration
(but not for calls!) is not necessarily a bad idea.

[O.T.]
If I am not mistaken "modern language" is so twisted that it can't
even have proper designated initializers for struct (proper =
arbitrary order). I don't know what is the reason for that, but the
reason exists.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04/07/2024 14:37, Bonita Montero wrote:

Am 04.07.2024 um 14:49 schrieb bart:

On 04/07/2024 12:12, Bonita Montero wrote:

Am 02.07.2024 um 18:53 schrieb Ivan Farlenkov:

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.

You can sort of already do it in C by using designated initializers
and macros
#define foo(A, B, C, ...) do{\
     stuct technical technical={\
         var1=default1,\
         var2=default2,\
         var3=default3 __VA_OPT__(,)\
         __VA_ARGS__\
     }\
     actual_foo(A, B, C, technical.var1, technical.var2,
technical.var3)\
}while(0)

What an anquated language that this needs macros.

How do you do it in C++?

With a inline-function that returns an auto to make the inner type accessible.

I meant, what do you have to do to get named arguments in C++?

Is it more of a nightmare than in C or less?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)