Block Comments Or Rest-Of-Line Comments?

[Lawrence D'Oliveiro]

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?

[bart]

Post by Lawrence D'Oliveiro
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
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.

Post by Lawrence D'Oliveiro
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.

[Mikko]

Post by Lawrence D'Oliveiro
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.

Post by Lawrence D'Oliveiro
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
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.

Post by Lawrence D'Oliveiro
Do you feel the same?

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

[Lawrence D'Oliveiro]

Post by Mikko

Post by Lawrence D'Oliveiro
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.

[David Brown]

Post by Lawrence D'Oliveiro

Post by Mikko

Post by Lawrence D'Oliveiro
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).

Post by Lawrence D'Oliveiro
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.

[Blue-Maned_Hawk]

Post by David Brown
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.

[Lawrence D'Oliveiro]

Post by David Brown

Post by Lawrence D'Oliveiro

Post by Mikko

Post by Lawrence D'Oliveiro
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?

[Chris M. Thomasson]

[...]

Post by Lawrence D'Oliveiro

Post by David Brown
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?

[Lawrence D'Oliveiro]

Post by Chris M. Thomasson

Post by Lawrence D'Oliveiro

Post by David Brown

Post by Lawrence D'Oliveiro
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?

[David Brown]

Post by Lawrence D'Oliveiro

Post by David Brown

Post by Lawrence D'Oliveiro

Post by Mikko

Post by Lawrence D'Oliveiro
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.)

[Malcolm McLean]

Post by Lawrence D'Oliveiro

Post by David Brown

Post by Lawrence D'Oliveiro

Post by Mikko

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

But a block in Python is either exactly or to all intents and purposes
the same thing as a block in C or many other programming languages. And
we already have perfectly good syntax for that. So why mess about?
Similarly comments are exactly the same in every programming language,
though to be fair C is a bit of an outlier and hashes are more conventional.

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

[Blue-Maned_Hawk]

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

[Richard Harnden]

Post by Blue-Maned_Hawk
I searched around a bit, and it seems like a more common way to implement
#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.

[Blue-Maned_Hawk]

Post by Richard Harnden

Post by Blue-Maned_Hawk
I searched around a bit, and it seems like a more common way to
#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?

[Richard Harnden]

Post by Blue-Maned_Hawk

Post by Richard Harnden

Post by Blue-Maned_Hawk
I searched around a bit, and it seems like a more common way to
#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 ...

[Kaz Kylheku]

Post by Richard Harnden

Post by Blue-Maned_Hawk

Post by Richard Harnden

Post by Blue-Maned_Hawk
I searched around a bit, and it seems like a more common way to
#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.

[bart]

Post by Blue-Maned_Hawk
I searched around a bit, and it seems like a more common way to implement
#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.

Post by Blue-Maned_Hawk
}
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

[Keith Thompson]

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

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

Probably, but not necessarily. The languages I'm familiar with that
support named parameters also support default values, but a language
could easily have one without the other. (I'm not saying that would be
a good idea.)

[...]

[Blue-Maned_Hawk]

Post by bart

Post by Blue-Maned_Hawk
I searched around a bit, and it seems like a more common way to
#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.

Post by bart

Post by Blue-Maned_Hawk
}
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.

Post by bart
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.)

Post by bart
double l, m, n
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.

[bart]

Post by Blue-Maned_Hawk

Post by bart

Post by Blue-Maned_Hawk
I searched around a bit, and it seems like a more common way to
#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.

Post by Blue-Maned_Hawk
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.

[Keith Thompson]

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

Post by bart
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);

See Message-ID <***@nosuchdomain.example.com>, posted last
August.

[Kaz Kylheku]

Post by Keith Thompson
[...]

Post by bart
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.

[Opus]

Post by bart

Post by Blue-Maned_Hawk
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.

[Lawrence D'Oliveiro]

Post by Ivan Farlenkov
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).

[Bonita Montero]

Post by Ivan Farlenkov

Post by David Brown
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.

[Michael S]

On Thu, 4 Jul 2024 13:12:18 +0200

Post by Bonita Montero

Post by Ivan Farlenkov

Post by David Brown
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.

[Michael S]

On Thu, 4 Jul 2024 15:02:49 +0300

Post by Michael S
On Thu, 4 Jul 2024 13:12:18 +0200

Post by Bonita Montero

Post by Ivan Farlenkov

Post by David Brown
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.

Post by Michael S
[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.

[bart]

Post by Bonita Montero

Post by Ivan Farlenkov

Post by David Brown
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++?

[Bonita Montero]

Post by bart

Post by Bonita Montero

Post by Ivan Farlenkov

Post by David Brown
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.

[Bonita Montero]

Post by Bonita Montero

Post by bart

Post by Bonita Montero

Post by Ivan Farlenkov

Post by David Brown
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.

... or just an additional constructor on a technical.

[bart]

Post by Bonita Montero

Post by bart

Post by Bonita Montero

Post by Ivan Farlenkov

Post by David Brown
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?

[Bonita Montero]

Post by bart

Post by Bonita Montero

Post by bart

Post by Bonita Montero

Post by Ivan Farlenkov

Post by David Brown
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?

With an additional constructor for technical everything is fine.

[Scott Lurndal]

Post by Lawrence D'Oliveiro
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.

[Tim Rentsch]

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.

[Dan Cross]

Post by Tim Rentsch

The original comment delimiters in C were copied from PL/I: everything

Cite?

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.

[Tim Rentsch]

Post by Dan Cross

Post by Tim Rentsch

The original comment delimiters in C were copied from PL/I: everything

Cite?

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.

[Dan Cross]

Post by Tim Rentsch

Post by Dan Cross

Post by Tim Rentsch

The original comment delimiters in C were copied from PL/I: everything

Cite?

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.

[Blue-Maned_Hawk]

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.

[David Brown]

Post by Lawrence D'Oliveiro
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.)

Post by Lawrence D'Oliveiro
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
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.

[Richard Harnden]

Post by David Brown

Post by Lawrence D'Oliveiro
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

[Keith Thompson]

Richard Harnden <***@gmail.invalid> writes:
[...]

Post by Richard Harnden
And sometimes, when it's not a really a comment, but rather a block of
#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.

[Richard Harnden]

Post by Keith Thompson
[...]

Post by Richard Harnden
And sometimes, when it's not a really a comment, but rather a block of
#ifdef 0
...
#endif

I think you mean "#if 0".

Yes I did :)

Post by Keith Thompson
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?

[Keith Thompson]

Post by Richard Harnden

Post by Keith Thompson
[...]

Post by Richard Harnden
And sometimes, when it's not a really a comment, but rather a block of
#ifdef 0
...
#endif

I think you mean "#if 0".

Yes I did :)

Post by Keith Thompson
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";
```

[Richard Harnden]

Post by Keith Thompson

Post by Richard Harnden

Post by Keith Thompson
[...]

Post by Richard Harnden
And sometimes, when it's not a really a comment, but rather a block of
#ifdef 0
...
#endif

I think you mean "#if 0".

Yes I did :)

Post by Keith Thompson
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 $newline = "\n";
if (defined $lines[0] and $lines[0] =~ /\r$/) {
$newline = "\r\n";
}
print "#if 0$newline";
if ($line =~ /^ /) {
$line =~ s/ /*/;
}
elsif ($line =~ /^\r?$/) {
$line =~ s/^/*/;
}
else {
$line =~ s/^/* /;
}
print $line;
}
print "#endif /* 0 */$newline";
```

Thank you

[Lawrence D'Oliveiro]

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.

[Keith Thompson]

Post by Lawrence D'Oliveiro

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

[Scott Lurndal]

Post by Keith Thompson
[...]

Post by Richard Harnden
And sometimes, when it's not a really a comment, but rather a block of
#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.

[Kaz Kylheku]

Post by Scott Lurndal

Post by Keith Thompson
[...]

Post by Richard Harnden
And sometimes, when it's not a really a comment, but rather a block of
#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.

[p***@paulglover.net.invalid]

Post by Kaz Kylheku
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.)

[Kaz Kylheku]

Post by Keith Thompson
[...]

Post by Richard Harnden
And sometimes, when it's not a really a comment, but rather a block of
#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.

[Keith Thompson]

Post by Kaz Kylheku

Post by Keith Thompson
[...]

Post by Richard Harnden
And sometimes, when it's not a really a comment, but rather a block of
#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.

[James Kuyper]

Post by Keith Thompson
[...]

Post by Richard Harnden
And sometimes, when it's not a really a comment, but rather a block of
#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.

[Keith Thompson]

Post by James Kuyper

Post by Keith Thompson
[...]

Post by Richard Harnden
And sometimes, when it's not a really a comment, but rather a block of
#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.

Just to be clear, the problem with "#ifdef 0" is that 0 is not an
identifier.

main.c:1:8: error: macro names must be identifiers
1 | #ifdef 0
| ^

[Lawrence D'Oliveiro]

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

[David Brown]

Post by Richard Harnden

Post by David Brown

Post by Lawrence D'Oliveiro
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
#ifdef 0

"#if 0", presumably.

Post by Richard Harnden
...
#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.

[fir]

Post by Lawrence D'Oliveiro
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
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

[Lawrence D'Oliveiro]

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

[Malcolm McLean]

Post by Lawrence D'Oliveiro
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
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 don't have strong views about this. Block comments occasionally used
to fail to match up, but with modern syntax highlighting, that is less
of an issue. It's also slightly more natural to use // comments when
commenting every line of a structure. The, as yiu say, if you want
comments interspersed with code in the same it, it must be the old
style, but it's very rare for that to be useful.

However until recently it wasn't unknown for the // comments to break.
So you couldn't use them in serious, portable C programming. I think
that's no longer the case.

[DFS]

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.

[Lawrence D'Oliveiro]

Post by DFS

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?

[Blue-Maned_Hawk]

Post by DFS
Get yourself some Notepad++.

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

[Sjouke Burry]

Post by Blue-Maned_Hawk

Post by DFS
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.

[Blue-Maned_Hawk]

Post by Sjouke Burry

Post by Blue-Maned_Hawk

Post by DFS
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.

[DFS]

Post by Blue-Maned_Hawk

Post by DFS
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.

[Blue-Maned_Hawk]

That's an unsubstantiated claim.

Post by DFS

Post by Blue-Maned_Hawk

Post by DFS
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.

[Chris M. Thomasson]

Post by Blue-Maned_Hawk
That's an unsubstantiated claim.

Post by DFS

Post by Blue-Maned_Hawk

Post by DFS
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.

If one cannot afford a 25 dollar computer, well, shit...

[DFS]

Post by Blue-Maned_Hawk
That's an unsubstantiated claim.

That's a fact.

Post by Blue-Maned_Hawk

Post by DFS

Post by Blue-Maned_Hawk

Post by DFS
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.

[Kaz Kylheku]

Post by Lawrence D'Oliveiro
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
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.

[Lowell Gilbert]

Post by Kaz Kylheku
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.

[Ben Bacarisse]

Post by Lowell Gilbert

Post by Kaz Kylheku
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.

[Lowell Gilbert]

Post by Ben Bacarisse

Post by Lowell Gilbert

Post by Kaz Kylheku
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.

[Kaz Kylheku]

Post by Lowell Gilbert

Post by Kaz Kylheku
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.

[p***@paulglover.net.invalid]

Post by Lawrence D'Oliveiro
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.

Post by Lawrence D'Oliveiro
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
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).