Recently, I wrote:

board & 1 << row * COLS + col

. Not knowing the precedence of operators by heart,
I planned to look up the precedence rules and then insert
any necessary parentheses. But then, I had this thought:
"C was made for such expression; just trust the language.".

On 4/8/22 08:00, Stefan Ram wrote:
> Recently, I wrote:
>
> board & 1 << row * COLS + col
>
> . Not knowing the precedence of operators by heart,
> I planned to look up the precedence rules and then insert
> any necessary parentheses. But then, I had this thought:
> "C was made for such expression; just trust the language.".

Most of C's precedence rules are well chosen, generally making more
common code patterns easier, while supporting less common patterns by
use of parenthesis. Unfortunately, there's a few exceptions. That
expression gets parsed as

board & (1 << ((row*COLS) + col))

I doubt that's what you intended.

If I remember correctly (this occurred well before my time, I've only
heard about it third-hand), originally a single operator was used for
both & and &&; and similarly for | and ||, which had the same precedence
as modern && and || respectively. Rather late in the process leading to
modern C, they were split, and & and | were given precedence just
slightly higher than && and ||, which turned out to be a bad decision.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 4/8/22 08:00, Stefan Ram wrote:
>> Recently, I wrote:
>>
>> board & 1 << row * COLS + col
>>
>> . Not knowing the precedence of operators by heart,
>> I planned to look up the precedence rules and then insert
>> any necessary parentheses. But then, I had this thought:
>> "C was made for such expression; just trust the language.".
>
> Most of C's precedence rules are well chosen, generally making more
> common code patterns easier, while supporting less common patterns by
> use of parenthesis. Unfortunately, there's a few exceptions. That
> expression gets parsed as
>
> board & (1 << ((row*COLS) + col))
>
> I doubt that's what you intended.

I'd have thought that's exactly what's intended!

The other possibility (with regard to &): (board & 1) << ... seems very
unlikely.

> If I remember correctly (this occurred well before my time, I've only
> heard about it third-hand), originally a single operator was used for
> both & and &&; and similarly for | and ||, which had the same precedence
> as modern && and || respectively. Rather late in the process leading to
> modern C, they were split, and & and | were given precedence just
> slightly higher than && and ||, which turned out to be a bad decision.

& and | didn't have their precedence changed. Since they were,
originally, the only way to do "and" and "or" they already had a
precedence that was too low for many natural bit-wise expressions.

The new && and || were give precedence just below & and | which was the
best that could be done without breaking lots of old code.

--
Ben.

On 4/8/2022 5:00 AM, Stefan Ram wrote:
> Recently, I wrote:
>
> board & 1 << row * COLS + col
>
> . Not knowing the precedence of operators by heart,
> I planned to look up the precedence rules and then insert
> any necessary parentheses. But then, I had this thought:
> "C was made for such expression; just trust the language.".

And?

Since you forgot to explain what your actual intent was, we can't really
fully appreciate the philosophical implications of your post.

Did the language justify your trust or betray it?

--
Best regards,
Andrey Tarasevich

In article <t2plh1$6fk$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> Most of C's precedence rules are well chosen, generally making more
> common code patterns easier, while supporting less common patterns by
> use of parenthesis. Unfortunately, there's a few exceptions. That
> expression gets parsed as

For a time I was thinking of Fortran rules where parentheses can
affect order of evaluation. Once I got that clear that
parentheses in C have no effect on generated code. So anytime Im
fuzzy on precedence, I just put in the parentheses and save my
brain for more important things.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>On 4/8/22 08:00, Stefan Ram wrote:
>> Recently, I wrote:
>>
>> board & 1 << row * COLS + col
>>
>> . Not knowing the precedence of operators by heart,
>> I planned to look up the precedence rules and then insert
>> any necessary parentheses. But then, I had this thought:
>> "C was made for such expression; just trust the language.".
>
>Most of C's precedence rules are well chosen, generally making more
>common code patterns easier, while supporting less common patterns by
>use of parenthesis. Unfortunately, there's a few exceptions. That
>expression gets parsed as
>
>board & (1 << ((row*COLS) + col))
>
>I doubt that's what you intended.

Perhaps ROWS*COLS <= (sizeof(board) << 3)?

On 08/04/2022 16:48, James Kuyper wrote:
> On 4/8/22 08:00, Stefan Ram wrote:
>> Recently, I wrote:
>>
>> board & 1 << row * COLS + col
>>
>> . Not knowing the precedence of operators by heart,
>> I planned to look up the precedence rules and then insert
>> any necessary parentheses. But then, I had this thought:
>> "C was made for such expression; just trust the language.".
>
> Most of C's precedence rules are well chosen,

My understanding is that most people would agree they are badly chosen.

Overall:

* There are too many to easily or reliably remember, or to be sure that
someone reading or maintaing your code knows them as well as you

* Many will puzzle over why = and < have different precedences

* Many won't see ehy bitwise ops ^ | & need to have different levels, or
why that order was chosen

* Many are unintuitive such as A << B + C. Since << scales just like *,
it makes sense for << and >> to work like * and / instead of whatever
they happen to be (I've no idea)

> generally making more
> common code patterns easier,

You can only really rely on people knowing the rules for +, * and **,
and probably = (ie. == in C). C doesn't have ** so that makes it even
easier.

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>board & 1 << row * COLS + col

How did that come up?

In a German-language newsgroup, someone explained: "An
empty square next to a piece is called a 'freedom' in Go.
For example, an isolated piece has four freedoms;
two adjacent tiles have six freedoms." He then asked:
"How can one arrange eight pieces so as to minimize the
number of their freedoms?"

I then wrote a small C program to try all possible
configurations of eight pieces on an 8×8 playing field,
and print those with a minimum number of freedoms.
The 8×8 playing field was a uint_fast64_t of stdint.h,
so COLS == 8.

On 08/04/2022 21:22, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> board & 1 << row * COLS + col
>
> How did that come up?
>
> In a German-language newsgroup, someone explained: "An
> empty square next to a piece is called a 'freedom' in Go.

Actually they're "liberties" for English speaking players, and a Chinese player explained that their
term translates as "breaths". (Perhaps "liberty" comes from a Japanese translation.)

> For example, an isolated piece has four freedoms;
> two adjacent tiles have six freedoms." He then asked:
> "How can one arrange eight pieces so as to minimize the
> number of their freedoms?"
>
> I then wrote a small C program to try all possible
> configurations of eight pieces on an 8×8 playing field,
> and print those with a minimum number of freedoms.
> The 8×8 playing field was a uint_fast64_t of stdint.h,
> so COLS == 8.
>
>

On 08/04/2022 22:46, Mike Terry wrote:
> On 08/04/2022 21:22, Stefan Ram wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> board & 1 << row * COLS + col
>>
>>    How did that come up?
>>
>>    In a German-language newsgroup, someone explained: "An
>>    empty square next to a piece is called a 'freedom' in Go.
>
> Actually they're "liberties" for English speaking players, and a Chinese player explained that their
> term translates as "breaths".  (Perhaps "liberty" comes from a Japanese translation.)

... and the go "stones" (not pieces) don't go in squares - the board is a grid of lines, and the
stones are placed on the intersections (referred to as "points") :)

>
>>    For example, an isolated piece has four freedoms;
>>    two adjacent tiles have six freedoms." He then asked:
>>    "How can one arrange eight pieces so as to minimize the
>>    number of their freedoms?"

That would be stuffing them all in a corner giving 5 liberties...

>>
>>    I then wrote a small C program to try all possible
>>    configurations of eight pieces on an 8×8 playing field,
>>    and print those with a minimum number of freedoms.
>>    The 8×8 playing field was a uint_fast64_t of stdint.h,
>>    so COLS == 8.

Coincidentally, I was working on a completely different puzzle last week, and wrote this (C#) code:

...
public static int BitNum (int x, int y)
{
return x + Program.gridsize * y;
}

public void SetBit(int x, int y)
{
int bitInd = BitNum(x, y);
if (bitInd < 64)
bits1 |= 1UL << bitInd;
else
bits2 |= 1UL << (bitInd - 64);
}
...

(same basic idea - there was a grid of squares whose occupancy/coverage was being tracked)
Hmm, I just prefer things more spread out I guess, and I don't trust my memory of operator precedence!

Mike.

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>On 08/04/2022 22:46, Mike Terry wrote:
>> On 08/04/2022 21:22, Stefan Ram wrote:
>>>For example, an isolated piece has four freedoms;
>>>two adjacent tiles have six freedoms." He then asked:
>>>"How can one arrange eight pieces so as to minimize the
>>>number of their freedoms?"
>That would be stuffing them all in a corner giving 5 liberties...

I think in the question asked, corners were not to be taken
into consideration. At least I assumed that my 8×8 grid
was embedded into a larger grid, so that it has no corners
in that sense.

Thanks for the explanation of the English Go terms!

>Hmm, I just prefer things more spread out I guess,

In the meantime, I also have refactored that expression into
two functions "free_at" and "free_" (i.e., "not occupied"):

#define BOARD uint_fast64_t
#define INDEX unsigned
#define SET ( ( BOARD )1 )

static inline int free_at
( BOARD const board, INDEX const i )
{ return !( board & SET << i ); }

static inline int free_
( BOARD const board, INDEX const row, INDEX const col )
{ return free_at( board, row * COLS + col ); }

.

On Friday, April 8, 2022 at 1:10:22 PM UTC-4, Siri Cruise wrote:
> In article <t2plh1$6fk$1...@dont-email.me>,
....
> For a time I was thinking of Fortran rules where parentheses can
> affect order of evaluation. Once I got that clear that
> parentheses in C have no effect on generated code.

Parentheses don't directly affect order of evaluation. They do,
however, do something far more important - they can change which
expressions are sub-expressions of other expressions, which has a
big effect on the generated code. In `a + b*c`, `b*c` is the right
operand of the `+` operator; in `(a + b)*c`, `a+b` is the left operand
of the `*` operator.

As a result, parentheses do indirectly affect the order of evaluation,
since evaluations of sub-expressions are sequenced before evaluation
of the expression they are part of. That is not enough to determine
the order of evaluation, but it does constrain the order.

Am 08.04.2022 um 14:00 schrieb Stefan Ram:
> Recently, I wrote:
>
> board & 1 << row * COLS + col
>
> . Not knowing the precedence of operators by heart,
> I planned to look up the precedence rules and then insert
> any necessary parentheses. But then, I had this thought:
> "C was made for such expression; just trust the language.".
>
>

Better use C++. With C++ you can use operator overloading and
with operator overloadig you can re-define the operator-precedence.
F.e. you can write:

unsigned u = 1;
cout << u << 1 << endl;
The second << is a shift now!!!

In article <t2uru3$1isf$1@gioia.aioe.org>,
Christian Hann <the.hanne@gmail.com> wrote:
>Am 08.04.2022 um 14:00 schrieb Stefan Ram:
>> Recently, I wrote:
>>
>> board & 1 << row * COLS + col
>>
>> . Not knowing the precedence of operators by heart,
>> I planned to look up the precedence rules and then insert
>> any necessary parentheses. But then, I had this thought:
>> "C was made for such expression; just trust the language.".
>>
>>
>
>Better use C++. With C++ ...

How about Fortran? Or Perl?

I.e., if you're going to suggest other, unrelated languages, why not go for
the sky?

I hear Python is big these days...

--

First of all, I do not appreciate your playing stupid here at all.

- Thomas 'PointedEars' Lahn -

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>static inline int free_at
>( BOARD const board, INDEX const i )
>{ return !( board & SET << i ); }

(Some explanation is given below starting with the line
starting with "The game of Go".)

#include <inttypes.h>
#include <limits.h>
#include <stdint.h>
#include <stdio.h>

#define UNSIGNED_INDEX unsigned
#define UNSIGNED_ROWS ( ( UNSIGNED_INDEX )8 )
#define UNSIGNED_COLS ( ( UNSIGNED_INDEX )8 )
#define UNSIGNED_LOCS ( ROWS * COLS )
#define CONFIGURATION uint_fast64_t
#define CONFIGURATION_MAX UINT_FAST64_MAX
#define STONE ( ( CONFIGURATION )1 )

/** \brief return 1 iff the point at offset i of the
one-dimensional representation of the board is free
of stones. */

static inline int free_1d
( CONFIGURATION const configuration, UNSIGNED_INDEX const i )
{ return !( configuration & STONE << i ); }

/** \brief return 1 iff the point at row, col carries a stone

\pre The position row, col must be on-board. */

static inline int free_2d_onboard
( CONFIGURATION const configuration,
UNSIGNED_INDEX const row, UNSIGNED_INDEX const col )
{ return free_1d( configuration, row * UNSIGNED_COLS + col ); }

/** \brief return 1 iff the point at row, col is free of stones

row, col pairs that belong to points outside the board are deemed
to be free of stones. */

static inline int free_2d
( CONFIGURATION const configuration,
UNSIGNED_INDEX const row, UNSIGNED_INDEX const col )
{ return row >= UNSIGNED_ROWS | col >= UNSIGNED_COLS |
free_2d_onboard( configuration, row, col ); }

/** \brief return 1 iff the point at row, col carries a stone */

static inline int exists
( CONFIGURATION const configuration,
UNSIGNED_INDEX const row, UNSIGNED_INDEX const col )
{ return !free_2d( configuration, row, col ); }

/** \brief return 1 iff the field at row, col is adjacent to a stone */

static int is_near_stone
( CONFIGURATION const configuration,
UNSIGNED_INDEX const row, UNSIGNED_INDEX const col )
{ int const n =
exists( configuration, row - 1, col )+
exists( configuration, row + 1, col )+
exists( configuration, row, col - 1 )+
exists( configuration, row, col + 1 );
return !!n; }

/** \brief return number of liberties of a configuration */

static int liberties_of_stones( CONFIGURATION const configuration )
{ int n = 0;
for( int row = -1; row <( signed )UNSIGNED_ROWS + 1; ++row )
for( int col = -1; col <( signed )UNSIGNED_COLS + 1; ++col )
n +=
!!( is_near_stone
( configuration,( UNSIGNED_INDEX )row,( UNSIGNED_INDEX )col )&
free_2d
( configuration,( UNSIGNED_INDEX )row,( UNSIGNED_INDEX )col ));
return n; }

/** \brief print a configuration of a board */

static void print_configuration( CONFIGURATION const configuration )
{ for( UNSIGNED_INDEX row = 0; row < UNSIGNED_ROWS; ++row )
{ for( UNSIGNED_INDEX col = 0; col < UNSIGNED_COLS; ++col )
printf( "%c", free_2d( configuration, row, col ) ? '+' : 'o' );
printf( "\n" ); }}

/** \brief find solutions to the minimum surface problem for Go stones

The game of Go is played on a grid; stones are placed on grid
intersections, which are called "points". So an single isolated stone
on a point has four points next to him. A black stone is captured by
four white stones taking away its "liberties", i.e., occupying the
empty points adjacent to the black stone. Two black stones at a certain
distance from each other have four liberties twice, but if one places
them next to each other, the number is reduced to six liberties.

This program tries to answer the questions:
What is the minimum number of liberties for 8 stones?
With which arrangement does one achieve this minimum number?

From now on we will only deal with stones of a single color, say,
white stones.

To do this, this program tries all possible configurations of an
8×8 board with eight white stones on the board, that is, the numbers
of liberties for all possible ways to place eight white stones on the
board are calculated.

Whenever a new mininum of the number of liberties or a configuration
with fewer than eleven liberties is found, the configuration is printed.

A configuration of a board is given by specifying for each point
whether there is a white stone on it.

\return 0
*/

int find_solutions( void )
{ int min_liberties = INT_MAX;
uint_fast64_t number_of_configurations_tested = 0;
int output_count = 0;
/* The nested for loops create all possible configurations of eight
stones (the positions of which are called p0, p1, ..., p7) on a board
with 8×8 points. */
for( int p7 = 7; p7 < 64; ++p7 )
for( int p6 = 6; p6 < p7; ++p6 )
for( int p5 = 5; p5 < p6; ++p5 )
for( int p4 = 4; p4 < p5; ++p4 )
for( int p3 = 3; p3 < p4; ++p3 )
for( int p2 = 2; p2 < p3; ++p2 )
for( int p1 = 1; p1 < p2; ++p1 )
for( int p0 = 0; p0 < p1; ++p0 )
{ CONFIGURATION const configuration =
STONE << p0 |
STONE << p1 |
STONE << p2 |
STONE << p3 |
STONE << p4 |
STONE << p5 |
STONE << p6 |
STONE << p7;
++number_of_configurations_tested;
int const number_of_liberties = liberties_of_stones
( configuration );
if( number_of_liberties < min_liberties | number_of_liberties < 11 )
{ min_liberties = number_of_liberties;
printf( "Output #%d\n", output_count++ );
printf( "%d liberties\n", number_of_liberties );
printf
( number_of_configurations_tested == 1 ?
"So far, %" PRIuFAST64 " configuration tested.\n\n" :
"So far, %" PRIuFAST64 " configurations tested.\n\n",
number_of_configurations_tested );
print_configuration( configuration );
printf( "\n" ); }} return 0; }

/** \brief main function, calls @c find_solutions */

int main( void ){ return find_solutions(); }

On 2022-04-10, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <t2uru3$1isf$1@gioia.aioe.org>,
> Christian Hann <the.hanne@gmail.com> wrote:
>>Am 08.04.2022 um 14:00 schrieb Stefan Ram:
>>> Recently, I wrote:
>>>
>>> board & 1 << row * COLS + col
>>>
>>> . Not knowing the precedence of operators by heart,
>>> I planned to look up the precedence rules and then insert
>>> any necessary parentheses. But then, I had this thought:
>>> "C was made for such expression; just trust the language.".
>>>
>>>
>>
>>Better use C++. With C++ ...
>
> How about Fortran? Or Perl?
>
> I.e., if you're going to suggest other, unrelated languages, why not go for
> the sky?

C++ is not an unrelated language; where you have C++, it is very well
integrated into the platform in that you can directly use header files
and libraries, using their native usage sytnax and all. Toolchains
often have both a C and C++ compiler. It's not unusual to be able to
convert C code to C++ without changing very much (certainly not its
overall organization); the executable is about the same size and
performance, and can have exactly the same dependencies, not to mention
deployment model.

Le 08/04/2022 à 14:00, Stefan Ram a écrit :
> Recently, I wrote:
>
> board & 1 << row * COLS + col

If I saw this coming from someone in my team, I would probably fire them. =)

I'm not even sure this is correct from what you really intended. But
even if it is, there's a rule in programming, IMO, that's above the
programming language's grammar: readability for us humans.

Code we write is meant for humans, not machines. That's something people
forget way too often. That's why we write using higher-level languages,
not assembly or even machine code. Or, look at the obfuscated C contest
and such. This is proper C from a language standpoint, but nothing you'd
want to deal with.

The readability rule that applies here is, if you need more than a few
seconds figuring out what a given statement exactly does, and may have
to even open the C standard to make sure, then it's badly written.
Rewrite it.

On 4/8/2022 8:46 PM, james...@alumni.caltech.edu wrote:
> On Friday, April 8, 2022 at 1:10:22 PM UTC-4, Siri Cruise wrote:
>> In article <t2plh1$6fk$1...@dont-email.me>,
> ...
>> For a time I was thinking of Fortran rules where parentheses can
>> affect order of evaluation. Once I got that clear that
>> parentheses in C have no effect on generated code.
>
> Parentheses don't directly affect order of evaluation. They do,
> however, do something far more important - they can change which
> expressions are sub-expressions of other expressions, which has a
> big effect on the generated code. In `a + b*c`, `b*c` is the right
> operand of the `+` operator; in `(a + b)*c`, `a+b` is the left operand
> of the `*` operator.
>
> As a result, parentheses do indirectly affect the order of evaluation,
> since evaluations of sub-expressions are sequenced before evaluation
> of the expression they are part of. That is not enough to determine
> the order of evaluation, but it does constrain the order.

This is lazy wording, which makes it incorrect. The "subexpression
before expression" sequencing you mention does not cover side effects.
It only covers value computations. What you are trying to say is what
the standard formulates as:

6.5 Expressions
1 [...] The value computations of the operands of an operator are
sequenced before the value computation of the result of the operator.

Note the specific reference to *value computations*. That is the correct
wording.

You can put as many parentheses in your expression as you want, they
won't have any effect on sequencing of side effects. So no, you cannot
just claim that parentheses introduce a "sequenced before" ordering
without explicitly stating that this ordering applies to value
computations only.

And, once again, whatever ordering your parentheses might introduce,
they introduce it in an Abstract C Machine. Until you somehow trace/tie
that ordering to observable behavior, it won't have any connection to
the behavior of your specific real-life compiler and your specific
real-life code.

--
Best regards,
Andrey Tarasevich

Guillaume <message@bottle.org> writes:
>Le 08/04/2022 à 14:00, Stefan Ram a écrit :
>>Recently, I wrote:
>>board & 1 << row * COLS + col
>If I saw this coming from someone in my team, I would probably fire them. =)

I find it cute when programming witlings write down their
fantasies of power. =)

Guillaume <message@bottle.org> writes:

> Le 08/04/2022 à 14:00, Stefan Ram a écrit :
>> Recently, I wrote:
>> board & 1 << row * COLS + col
>
> If I saw this coming from someone in my team, I would probably fire
> them. =)

Why is this such a common trope? I doubt any country has such poor
employment protection that anyone could be fired for such a thing so I
assume it's just a rhetorical device to say "I really care about this
issue", but surely there are other ways to do that without being so
Donal^H^H^H^H Alan Sugar about it.

Anyway, in reality I imagine you'd help your team mate write code that
conforms to whatever standards your employer (or you, if you own the
company) demands, including some answer to the thorny question below.

> The readability rule that applies here is, if you need more than a few
> seconds figuring out what a given statement exactly does, and may have
> to even open the C standard to make sure, then it's badly
> written. Rewrite it.

The trouble with this (since I don't think you literally mean "you"
here) is who is the typical reader? Do you aim for the lowest common
denominator, or something in the middle? Does is vary by team? If it's
a C compiler project, might you assume a higher standard of
comprehension?

--
Ben.

On 10/04/2022 19:25, Stefan Ram wrote:
> Guillaume <message@bottle.org> writes:
>> Le 08/04/2022 à 14:00, Stefan Ram a écrit :
>>> Recently, I wrote:
>>> board & 1 << row * COLS + col
>> If I saw this coming from someone in my team, I would probably fire them. =)
>
> I find it cute when programming witlings write down their
> fantasies of power. =)
>
I don't think I'd fire them. But I think I'd explain that if they really
want to make a career in software engineering they need to understand
that making the program easily understood without ambiguity by everybody
is quite high on the list of requirements.

I'd also be pretty sure that they are early in their career, or they
would have learned that themselves by now. New graduates do need
tuition, and can become good engineers in time.

(IMHO about the only thing APL got right was the precedence. You start
at the end of the statement, and work along. It was the wrong end, but
WTH...)

(also AIUI precedence of operators only came about because
mathematicians like to write a+bc, meaning what we read as a+b*c)

Andy

Christian Hanné <the.hanne@gmail.com> writes:
> Am 08.04.2022 um 14:00 schrieb Stefan Ram:
>> Recently, I wrote:
>> board & 1 << row * COLS + col
>> . Not knowing the precedence of operators by heart,
>> I planned to look up the precedence rules and then insert
>> any necessary parentheses. But then, I had this thought:
>> "C was made for such expression; just trust the language.".
>>
>
> Better use C++. With C++ you can use operator overloading and
> with operator overloadig you can re-define the operator-precedence.
> F.e. you can write:
>
> unsigned u = 1;
> cout << u << 1 << endl;
> The second << is a shift now!!!

That is a lie. C++ operator overloading does not alter operator
precedence.

Christian Hanné has a pathetic history of posting deliberate
misinformation in comp.lang.c and comp.lang.c++.

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

Am 10.04.2022 um 23:17 schrieb Keith Thompson:
> Christian Hanné <the.hanne@gmail.com> writes:
>> Am 08.04.2022 um 14:00 schrieb Stefan Ram:
>>> Recently, I wrote:
>>> board & 1 << row * COLS + col
>>> . Not knowing the precedence of operators by heart,
>>> I planned to look up the precedence rules and then insert
>>> any necessary parentheses. But then, I had this thought:
>>> "C was made for such expression; just trust the language.".
>>>
>>
>> Better use C++. With C++ you can use operator overloading and
>> with operator overloadig you can re-define the operator-precedence.
>> F.e. you can write:
>>
>> unsigned u = 1;
>> cout << u << 1 << endl;
>> The second << is a shift now!!!
>
> That is a lie. C++ operator overloading does not alter operator
> precedence.

C++ allows defining your own operator-predence priorities since C++17.

Knowing the operator precedence is as essential as literacy.

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>Guillaume <message@bottle.org> writes:
>>Le 08/04/2022 à 14:00, Stefan Ram a écrit :
>>>Recently, I wrote:
>>>board & 1 << row * COLS + col
>>If I saw this coming from someone in my team, I would probably fire them. =)
>I find it cute when programming witlings write down their
>fantasies of power. =)

Could you play this sonata for us?

Pianist plays the Beethoven Sonata from memory.
(He also knows some other pieces by heart.)

Could you translate this sentence for us?

Translator translates the sentence, after having learned
more than 10000 words, many of which have several forms
and meanings, idioms, and complex rules of grammar and
usage.

Could you explain "a & b << c + 1" for us?

Look Sir, I'm a professional C programmer, doing this eight
hours a day, 40 hours a week, for many years. But C has
about 17 levels of precedence! Memorizing all of them is
simply beyond human capabilities! So please give me some parens.
I would say, otherwise, you would be to blame for having
written such a cluttered mess!

~~~

C is a language with some subtleties, and programming often
is somewhat complex overall. If you don't trust a C programmer
to even get an expression as simple as "a & b << c + 1",
how is he supposed to get more subtle things right?