imo c in some way is to make programmer not thing liek in assembler when
you need to hardly mentally focus but you use some plain c constructions
(it is not on all c becouse some c is really convoluted ;c)

if so you need easy if an sometimes those if else
ladders are not enough plain imo


this mean some needs some other construction that should be easier to read

see for example this code


if(dodge <1.)
{
if(dodge < .5)
{ slog("%s easily dodged attack...", being[k].name); }
else if(dodge > .9)
{ slog("%s hardly dodged attack...", being[k].name); }
else
slog("%s dodged attack...", being[k].name);

return 1;
}

imo its not readable, switch is also bad here, some needs something
other here soem other if realated construction





--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

imo c in some way is to make programmer not thing liek in assembler when
you need to hardly mentally focus but you use some plain c constructions
(it is not on all c becouse some c is really convoluted ;c)

if so you need easy if an sometimes those if else
ladders are not enough plain imo

this mean some needs some other construction that should be easier to read

see for example this code

if(dodge <1.)
{
ÿ if(dodge < .5)
ÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿ else if(dodge > .9)
ÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿ else
ÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

ÿ return 1;
ÿÿÿÿÿÿÿ }

imo its not readable, switch is also bad here, some needs something
other here soem other if realated construction

maye instead of such "if() /**/ else" there should be word case


case(a<2) {}
case (a>19) {}
else {}



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 05/09/2026 12:43, fir wrote:

imo c in some way is to make programmer not thing liek in assembler when
you need to hardly mentally focus but you use some plain c constructions
(it is not on all c becouse some c is really convoluted ;c)

if so you need easy if an sometimes those if else
ladders are not enough plain imo

this mean some needs some other construction that should be easier to read

see for example this code

if(dodge <1.)
{
ÿ if(dodge < .5)
ÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿ else if(dodge > .9)
ÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿ else
ÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

ÿ return 1;
ÿÿÿÿÿÿÿ }

imo its not readable, switch is also bad here, some needs something
other here soem other if realated construction

It's not the if-else that is the problem here; the example is dominated
by those slog calls.

However your coding style doesn't help, with badly placed and
inconsistent use of braces. The logic here is this:

#define sdodge(x) slog("%s" x "dodged attack...", being[k], name)

if (dodge < 1.0) {
if (dodge < 0.5) sdodge("easily ");
else if (dodge > 0.9) sdodge("hardly ");
else sdodge("");

return 1;
}

Switch is not going to be useful in this case, unless you call a
function that takes 'dodge' and returns a 1/2/3 category code.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

bart pisze:

On 05/09/2026 12:43, fir wrote:

imo c in some way is to make programmer not thing liek in assembler
when you need to hardly mentally focus but you use some plain c
constructions (it is not on all c becouse some c is really convoluted ;c)

if so you need easy if an sometimes those if else
ladders are not enough plain imo


this mean some needs some other construction that should be easier to
read

see for example this code


if(dodge <1.)
{
ÿÿ if(dodge < .5)
ÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿ else if(dodge > .9)
ÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿ else
ÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

ÿÿ return 1;
ÿÿÿÿÿÿÿÿ }

imo its not readable, switch is also bad here, some needs something
other here soem other if realated construction

It's not the if-else that is the problem here; the example is dominated
by those slog calls.

However your coding style doesn't help, with badly placed and
inconsistent use of braces. The logic here is this:

ÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], name)

ÿ if (dodge < 1.0) {
ÿÿÿÿÿÿÿÿÿÿ if (dodge < 0.5) sdodge("easily ");
ÿÿÿÿÿ else if (dodge > 0.9) sdodge("hardly ");
ÿÿÿÿÿ elseÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sdodge("");

ÿÿÿÿÿ return 1;
ÿ }

Switch is not going to be useful in this case, unless you call a
function that takes 'dodge' and returns a 1/2/3 category code.

my coding style here is bad i know (this dodge variable is wrong as its
more like "hit quality" above 1 its hit the more the better , below 1 is
miss , 0.9 meand berelly missed etc

but the if ladders ARE shit and are not quick (brainless) readable

ifs block is like "serial"

if(a<2)
if(a>3)
if(a<0)
if(a>4)
if(a<9)

here

ehen you need also "going-thru" but something like "switch" indeed
but it should be probbaly switch if not weird switch construction

if else block is also "serial" (and its reading proces is also "serial")
and you dont need "serial"

i dont know what world it should be but something like case but with no
head of switch

case(a<1) {}
case(a>3) {}
case(a<8) {}
case {}


you need also this tail but preferably it could be the ame keyword
maybe (though here case dont fits becouse it should mean not "any case"
but "other case"

it also should go thru all cases that "catched" the condition
but should not go down like in classic switch (classic switch i dont
like and i dont use - i use this if else ladders but i dislike its readibility)



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

bart pisze:

On 05/09/2026 12:43, fir wrote:

imo c in some way is to make programmer not thing liek in assembler
when you need to hardly mentally focus but you use some plain c
constructions (it is not on all c becouse some c is really convoluted
;c)

if so you need easy if an sometimes those if else
ladders are not enough plain imo


this mean some needs some other construction that should be easier to
read

see for example this code


if(dodge <1.)
{
ÿÿ if(dodge < .5)
ÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿ else if(dodge > .9)
ÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿ else
ÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

ÿÿ return 1;
ÿÿÿÿÿÿÿÿ }

imo its not readable, switch is also bad here, some needs something
other here soem other if realated construction

It's not the if-else that is the problem here; the example is
dominated by those slog calls.

However your coding style doesn't help, with badly placed and
inconsistent use of braces. The logic here is this:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], name)

ÿÿ if (dodge < 1.0) {
ÿÿÿÿÿÿÿÿÿÿÿ if (dodge < 0.5) sdodge("easily ");
ÿÿÿÿÿÿ else if (dodge > 0.9) sdodge("hardly ");
ÿÿÿÿÿÿ elseÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sdodge("");

ÿÿÿÿÿÿ return 1;
ÿÿ }

Switch is not going to be useful in this case, unless you call a
function that takes 'dodge' and returns a 1/2/3 category code.

my coding style here is bad i know (this dodge variable is wrong as its
more like "hit quality" above 1 its hit the more the better , below 1 is miss , 0.9 meand berelly missed etc

but the if ladders ARE shit and are not quick (brainless) readable

ifs block is like "serial"

if(a<2)
if(a>3)
if(a<0)
if(a>4)
if(a<9)

here

ehen you need also "going-thru" but something like "switch" indeed
but it should be probbaly switch ifÿ not weird switch construction

if else block is also "serial" (and its reading proces is also "serial")
and you dont need "serial"

i dont know what world it should be but something like case but with no
head of switch

case(a<1) {}
case(a>3) {}
case(a<8) {}
caseÿÿÿÿÿÿ {}

you need also this tail but preferably it could be the ame keyword
maybe (though here case dont fits becouse it should mean not "any case"
but "other case"

it also should go thru all cases that "catched" the condition
but should not go down like in classic switch (classic switch i dont
like and i dont use - i use this if else ladders but i dislike its readibility)

what i say here is probably proper and logical critique of switch in c
as it is (not that im in logical form, im in terrible imo)

also i hope i do not made any logical error coz maybe i did
(it should be yet checked)

becouse here i say this branches should be like in parallel
not serial and yet it should catch in many cases, so i need
to check it


case(a<8) {}
case(a<4) {}
case(a>2) {}
case {}

this should work and be read naturally i mean for a=3 three branches
should go



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

ÿ if(dodge < .5)
ÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿ else if(dodge > .9)
ÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿ else
ÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

eventually check my oryginal example here i could use if block which is
okay readable

if(dodge < .5) slog("a");
if(dodge > .9) slog("b");
slog("c");

but it is impossible becouse i want "a" or "b" or "c" not "ab" "ac"

so i could turn it into if-else block but then its not readable
or ake it yet more complex.. and all ot those 3 cases are wrong when
this solution i postulate would go welll


case (dodge < .5) slog("a");
case (dodge > .9) slog("b");
othercase slog("c");






--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

fir pisze:

ÿÿ if(dodge < .5)
ÿÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿÿ else if(dodge > .9)
ÿÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿÿ else
ÿÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

eventually check my oryginal example here i could use if block which is
okay readable

ÿÿ if(dodge < .5) slog("a");
ÿÿ if(dodge > .9) slog("b");
ÿÿ slog("c");

but it is impossible becouse i want "a" or "b" or "c" not "ab" "ac"

so i could turn it into if-else block but then its not readable
or ake it yet more complex.. and all ot those 3 cases are wrong when
this solution i postulate would go welll

ÿÿ case (dodge < .5) slog("a");
ÿÿ case (dodge > .9) slog("b");
ÿÿ othercase slog("c");

yet tu note the diference if-else blocks exit on first occurance

if blocks go thru all

what you need here (to assume and thus not READ IN like in convoluted assembly) in neitrer one or another

you need like if block and then othercase keyword branch which will
go only if no one "if block" catched

- (and this is probably minimal syntax for so called switch - which in
turn is wrong in c becouse is not minimal and breaks the strict rules
here imo (probably))



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

fir pisze:

fir pisze:

ÿÿ if(dodge < .5)
ÿÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿÿ else if(dodge > .9)
ÿÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿÿ else
ÿÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

eventually check my oryginal example here i could use if block which is
okay readable

ÿÿÿ if(dodge < .5) slog("a");
ÿÿÿ if(dodge > .9) slog("b");
ÿÿÿ slog("c");

but it is impossible becouse i want "a" or "b" or "c" not "ab" "ac"

so i could turn it into if-else block but then its not readable
or ake it yet more complex.. and all ot those 3 cases are wrong when
this solution i postulate would go welll


ÿÿÿ case (dodge < .5) slog("a");
ÿÿÿ case (dodge > .9) slog("b");
ÿÿÿ othercase slog("c");

yet tu note the diference if-else blocks exit on first occurance

if blocks go thru all

what you need here (to assume and thus not READ IN like in convoluted assembly) in neitrer one orÿ another

you need like if block and then othercase keyword branch which will
go only if no one "if block" catched

- (and this is probably minimal syntax for so called switch - which in
turn is wrong in c becouse is not minimal and breaks the strict rules
here imo (probably))

one could also say it could be resolved by make extended else
like
x
.if () [}
.if () {}
if () {}
if () {}
.else {}

this else catches if all of those .if not catched not only one

OR it may suggest an option for logical combining ifs


if(a) {}
& if(b) {}
| if(c) {}
else {} //alse work only on logical combination


so there are some new possibilities here




--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

fir pisze:

fir pisze:

fir pisze:

ÿÿ if(dodge < .5)
ÿÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿÿ else if(dodge > .9)
ÿÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿÿ else
ÿÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

eventually check my oryginal example here i could use if block which is
okay readable

ÿÿÿ if(dodge < .5) slog("a");
ÿÿÿ if(dodge > .9) slog("b");
ÿÿÿ slog("c");

but it is impossible becouse i want "a" or "b" or "c" not "ab" "ac"

so i could turn it into if-else block but then its not readable
or ake it yet more complex.. and all ot those 3 cases are wrong when
this solution i postulate would go welll


ÿÿÿ case (dodge < .5) slog("a");
ÿÿÿ case (dodge > .9) slog("b");
ÿÿÿ othercase slog("c");

yet tu note the diference if-else blocks exit on first occurance

if blocks go thru all

what you need here (to assume and thus not READ IN like in convoluted
assembly) in neitrer one orÿ another

you need like if block and then othercase keyword branch which will
go only if no one "if block" catched

- (and this is probably minimal syntax for so called switch - which in
turn is wrong in c becouse is not minimal and breaks the strict rules
here imo (probably))

one could also say it could be resolved by make extended else
like
x
.if () [}
.if () {}
if () {}
if () {}
.else {}

this else catches if all of those .if not catched not only one

OR it may suggest an option for logical combining ifs

if(a) {}
& if(b) {}
| if(c) {}
else {} //alse work only on logical combination

so there are some new possibilities here

so this 'classical' switch im talking here would be

if(){}
or if() {}
or if() {}
or if() {}
else {}


i dont know if thi logical keywords would be more handy or just this
improved switch would be most handy

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

fir pisze:

fir pisze:

fir pisze:

fir pisze:

ÿÿ if(dodge < .5)
ÿÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿÿ else if(dodge > .9)
ÿÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿÿ else
ÿÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

eventually check my oryginal example here i could use if block which is >>>> okay readable

ÿÿÿ if(dodge < .5) slog("a");
ÿÿÿ if(dodge > .9) slog("b");
ÿÿÿ slog("c");

but it is impossible becouse i want "a" or "b" or "c" not "ab" "ac"

so i could turn it into if-else block but then its not readable
or ake it yet more complex.. and all ot those 3 cases are wrong when
this solution i postulate would go welll


ÿÿÿ case (dodge < .5) slog("a");
ÿÿÿ case (dodge > .9) slog("b");
ÿÿÿ othercase slog("c");

yet tu note the diference if-else blocks exit on first occurance

if blocks go thru all

what you need here (to assume and thus not READ IN like in convoluted
assembly) in neitrer one orÿ another

you need like if block and then othercase keyword branch which will
go only if no one "if block" catched

- (and this is probably minimal syntax for so called switch - which
in turn is wrong in c becouse is not minimal and breaks the strict
rules here imo (probably))

one could also say it could be resolved by make extended else
like
x
.if () [}
.if () {}
if () {}
if () {}
.else {}

this else catches if all of those .if not catched not only one

OR it may suggest an option for logical combining ifs


if(a) {}
& if(b) {}
| if(c) {}
else {} //alse work only on logical combination


so there are some new possibilities here

so this 'classical' switch im talking here would be

ÿ if(){}
or if() {}
orÿ if() {}
or if() {}
else {}

i dont know if thi logical keywords would be more handy or just this improved switch would be most handy

hovevevr the separation of if and else is alos idea to consider

would that be useful

if(a<0) {printf("-");}

printf("zzz");

else {printf("+");}

in fact "then" keyword also would be handy becouse


if(a<0) {printf("-");}

printf("zzz");

then {printf("+");}




--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 05/09/2026 14:10, bart wrote:

On 05/09/2026 12:43, fir wrote:

imo c in some way is to make programmer not thing liek in assembler
when you need to hardly mentally focus but you use some plain c
constructions (it is not on all c becouse some c is really convoluted ;c)

if so you need easy if an sometimes those if else
ladders are not enough plain imo


this mean some needs some other construction that should be easier to
read

see for example this code


if(dodge <1.)
{
ÿÿ if(dodge < .5)
ÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿ else if(dodge > .9)
ÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿ else
ÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

ÿÿ return 1;
ÿÿÿÿÿÿÿÿ }

imo its not readable, switch is also bad here, some needs something
other here soem other if realated construction

It's not the if-else that is the problem here; the example is dominated
by those slog calls.

However your coding style doesn't help, with badly placed and
inconsistent use of braces. The logic here is this:

ÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], name)

ÿ if (dodge < 1.0) {
ÿÿÿÿÿÿÿÿÿÿ if (dodge < 0.5) sdodge("easily ");
ÿÿÿÿÿ else if (dodge > 0.9) sdodge("hardly ");
ÿÿÿÿÿ elseÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sdodge("");

ÿÿÿÿÿ return 1;
ÿ }

Switch is not going to be useful in this case, unless you call a
function that takes 'dodge' and returns a 1/2/3 category code.

Your bracing style is also questionable - for many reasons, it is common
in style guides to recommend braces whenever you have "else" clauses,
and even more so when macros are involved.

And while refactoring out the common code is a good idea, it is almost
always best to use functions for the job.


static void sdodge(int being_index, const char * adj) {
slog("%s %sdodged attack...", being[being_index].name, adj);
}

...
if (dodge < 1.0) {
if (dodge < 0.5) {
sdodge(k, "easily ");
} else if (dodge > 0.9) {
sdodge(k, "hardly ");
} else {
sdodge(k, "");
}
return 1;
}
...

This is easier to change if you need to add more to the different
clauses, or if sdodge() needs more statements.

It is also possible to use the tertiary operator, which some people
might feel is clearer :

...
if (dodge < 1.0) {
sdodge(k, (dodge < 0.5) ? "easily " :
(dodge > 0.9) ? "hardly " :
"");
return 1;
}
...

Even better, perhaps, the classification part could be pulled out :

typedef enum { dodge_easy, dodge_medium, dodge_hard } dodge_style_t;
const char * dodge_adjectives[] = { "easily ", "", "hardly " };

dodge_style_t dodge_style_from_frac(double x) {
if (dodge < 0.5) return dodge_easy;
if (dodge > 0.9) return dodge_hard;
return dodge_medium;
}

...
if (dodge < 1.0) {
slog("%s %sdodged attack...", being[k].name,
dodge_adjectives[dodge_style_from_frac[dodge]));

return 1;
}
...

Now it's a lot easier to change things if other dodge styles are added,
or the boundaries are changed - there are fewer "magic numbers" in the
main code.






--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown pisze:

On 05/09/2026 14:10, bart wrote:

On 05/09/2026 12:43, fir wrote:

imo c in some way is to make programmer not thing liek in assembler
when you need to hardly mentally focus but you use some plain c
constructions (it is not on all c becouse some c is really convoluted
;c)

if so you need easy if an sometimes those if else
ladders are not enough plain imo


this mean some needs some other construction that should be easier to
read

see for example this code


if(dodge <1.)
{
ÿÿ if(dodge < .5)
ÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿ else if(dodge > .9)
ÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿ else
ÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

ÿÿ return 1;
ÿÿÿÿÿÿÿÿ }

imo its not readable, switch is also bad here, some needs something
other here soem other if realated construction

It's not the if-else that is the problem here; the example is
dominated by those slog calls.

However your coding style doesn't help, with badly placed and
inconsistent use of braces. The logic here is this:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], name)

ÿÿ if (dodge < 1.0) {
ÿÿÿÿÿÿÿÿÿÿÿ if (dodge < 0.5) sdodge("easily ");
ÿÿÿÿÿÿ else if (dodge > 0.9) sdodge("hardly ");
ÿÿÿÿÿÿ elseÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sdodge("");

ÿÿÿÿÿÿ return 1;
ÿÿ }

Switch is not going to be useful in this case, unless you call a
function that takes 'dodge' and returns a 1/2/3 category code.

Your bracing style is also questionable - for many reasons, it is common
in style guides to recommend braces whenever you have "else" clauses,
and even more so when macros are involved.

And while refactoring out the common code is a good idea, it is almost always best to use functions for the job.

static void sdodge(int being_index, const char * adj) {
ÿÿÿÿslog("%sÿ %sdodged attack...", being[being_index].name, adj);
}

ÿÿÿÿ...
ÿÿÿÿif (dodge < 1.0) {
ÿÿÿÿÿÿÿ if (dodge < 0.5) {
ÿÿÿÿÿÿÿÿÿÿÿ sdodge(k, "easily ");
ÿÿÿÿÿÿÿ } else if (dodge > 0.9) {
ÿÿÿÿÿÿÿÿÿÿÿ sdodge(k, "hardly ");
ÿÿÿÿÿÿÿ } else {
ÿÿÿÿÿÿÿÿÿÿÿ sdodge(k, "");
ÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿ return 1;
ÿÿÿÿ}
ÿÿÿÿ...

i may agree with this above but that is not a point of my remarks

as to separating function it seem to be right way in this typ of
rogualice code i write but presently i find it situational

1) in some ocdes when you make separate function it need you create like
one more dependency/jump becouse you then need to jump there or avoid it
when you scroll page of text - so in many cases its not good to make
separate functions

2) in some more codes its good to make then as you get more clarity
form codes - and thsi seem to be that case hovever if you do that imo
you would need longer descriptive neme becouse if you do it short
you get +1 obscurity here

so -1 jump is good +1 obscurity is bad, here +2 clarity justifies a -1
for separation/dependency/jump small jump but its situational imo

This is easier to change if you need to add more to the different
clauses, or if sdodge() needs more statements.

It is also possible to use the tertiary operator, which some people
might feel is clearer :

ÿÿÿÿ...
ÿÿÿÿif (dodge < 1.0) {
ÿÿÿÿÿÿÿ sdodge(k, (dodge < 0.5) ? "easily " :
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ (dodge > 0.9) ? "hardly " :
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ "");
ÿÿÿÿÿÿÿ return 1;
ÿÿÿÿ}
ÿÿÿÿ...

Even better, perhaps, the classification part could be pulled out :

typedef enum { dodge_easy, dodge_medium, dodge_hard } dodge_style_t;
const char * dodge_adjectives[] = { "easily ", "", "hardly " };

dodge_style_t dodge_style_from_frac(double x) {
ÿÿÿÿif (dodge < 0.5) return dodge_easy;
ÿÿÿÿif (dodge > 0.9) return dodge_hard;
ÿÿÿÿreturn dodge_medium;
}

ÿÿÿÿ...
ÿÿÿÿif (dodge < 1.0) {
ÿÿÿÿÿÿÿ slog("%sÿ %sdodged attack...", being[k].name,
ÿÿÿÿÿÿÿÿÿÿÿ dodge_adjectives[dodge_style_from_frac[dodge]));

ÿÿÿÿÿÿÿ return 1;
ÿÿÿÿ}
ÿÿÿÿ...

Now it's a lot easier to change things if other dodge styles are added,
or the boundaries are changed - there are fewer "magic numbers" in the
main code.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

On 05/09/2026 12:43, fir wrote:

imo c in some way is to make programmer not thing liek in assembler
when you need to hardly mentally focus but you use some plain c
constructions (it is not on all c becouse some c is really
convoluted ;c)

if so you need easy if an sometimes those if else
ladders are not enough plain imo

(Your "English" is really hard to decipher. - I suggest to use Google
to translate your texts from your native language into something that
is much better understandable and post that translation. - The Google translator is easily accessible from your browser.)

this mean some needs some other construction that should be easier to
read

see for example this code


if(dodge <1.)
{
ÿÿ if(dodge < .5)
ÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿ else if(dodge > .9)
ÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿ else
ÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

ÿÿ return 1;
ÿÿÿÿÿÿÿÿ }

I'd use a function to encapsulate the logging statements; they all
have the same basic structure and you'd avoid all the duplicates.

imo its not readable, switch is also bad here, some needs something
other here soem other if realated construction

As I wrote in some recent post; "I don't think that situation isn't
under control of the individual software writer; you could change
that situation." - Here as well; you have the the possibility to
structure your code. - And while (what you wrote above) "some c is
really convoluted" might be in principle true you seem to expose
some fundamental lack of capability to appropriately structure your
code. (In this case, BTW, a switch to another language with more
structuring options would also not help. Your problem here isn't
primarily or basically a "C" issue.)

It's not the if-else that is the problem here; the example is
dominated by those slog calls.

However your coding style doesn't help, with badly placed and
inconsistent use of braces. The logic here is this:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], name)

(It's beyond me why one would prefer macros to a function here.
But your basic idea to extract the invariant is of course sensible.)

ÿÿ if (dodge < 1.0) {
ÿÿÿÿÿÿÿÿÿÿÿ if (dodge < 0.5) sdodge("easily ");
ÿÿÿÿÿÿ else if (dodge > 0.9) sdodge("hardly ");
ÿÿÿÿÿÿ elseÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sdodge("");

ÿÿÿÿÿÿ return 1;
ÿÿ }

Much better readable.

Switch is not going to be useful in this case, unless you call a
function that takes 'dodge' and returns a 1/2/3 category code.

Your bracing style is also questionable - for many reasons, it is common
in style guides to recommend braces whenever you have "else" clauses,
and even more so when macros are involved.

(A matter of opinion, for sure. - I think his structuring is fine
here; a case of a simple linear cascade with a plain statement in
the branches; it is a most readable form without the ballast of
superfluous braces. - YMMV.)

And while refactoring out the common code is a good idea, it is almost always best to use functions for the job.

Indeed.

static void sdodge(int being_index, const char * adj) {
ÿÿÿÿslog("%sÿ %sdodged attack...", being[being_index].name, adj);
}

ÿÿÿÿ...
ÿÿÿÿif (dodge < 1.0) {
ÿÿÿÿÿÿÿ if (dodge < 0.5) {
ÿÿÿÿÿÿÿÿÿÿÿ sdodge(k, "easily ");
ÿÿÿÿÿÿÿ } else if (dodge > 0.9) {
ÿÿÿÿÿÿÿÿÿÿÿ sdodge(k, "hardly ");
ÿÿÿÿÿÿÿ } else {
ÿÿÿÿÿÿÿÿÿÿÿ sdodge(k, "");
ÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿ return 1;
ÿÿÿÿ}
ÿÿÿÿ...

What I'm often doing is to extract the strings, alike

if (dodge < 1.0) {
char * qualif = dodge < 0.5 ? "easily " :
dodge > 0.9 ? "hardly " : "";

sdodge (k, qualif);
return 1;
}

(add 'const' as desired, if supported).

This is easier to change if you need to add more to the different
clauses, or if sdodge() needs more statements.

It is also possible to use the tertiary operator, which some people
might feel is clearer :

ÿÿÿÿ...
ÿÿÿÿif (dodge < 1.0) {
ÿÿÿÿÿÿÿ sdodge(k, (dodge < 0.5) ? "easily " :
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ (dodge > 0.9) ? "hardly " :
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ "");
ÿÿÿÿÿÿÿ return 1;
ÿÿÿÿ}
ÿÿÿÿ...

Yes, though I prefer (see above) to avoid or try to reduce complex
expressions and not inline the conditional cascade in the function
call but separate it. (I admit it's "more stuff" with the extra
variable, maybe considered a bit "harder" to read than your inlined
version?)

Even better, perhaps, the classification part could be pulled out :

typedef enum { dodge_easy, dodge_medium, dodge_hard } dodge_style_t;
const char * dodge_adjectives[] = { "easily ", "", "hardly " };

(IMO that's too much for nothing.)

dodge_style_t dodge_style_from_frac(double x) {
ÿÿÿÿif (dodge < 0.5) return dodge_easy;
ÿÿÿÿif (dodge > 0.9) return dodge_hard;
ÿÿÿÿreturn dodge_medium;
}

ÿÿÿÿ...
ÿÿÿÿif (dodge < 1.0) {
ÿÿÿÿÿÿÿ slog("%sÿ %sdodged attack...", being[k].name,
ÿÿÿÿÿÿÿÿÿÿÿ dodge_adjectives[dodge_style_from_frac[dodge]));

ÿÿÿÿÿÿÿ return 1;
ÿÿÿÿ}
ÿÿÿÿ...

Now it's a lot easier to change things if other dodge styles are added,
or the boundaries are changed - there are fewer "magic numbers" in the
main code.

Janis


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

On 05/09/2026 12:43, fir wrote:

imo c in some way is to make programmer not thing liek in assembler
when you need to hardly mentally focus but you use some plain c
constructions (it is not on all c becouse some c is really
convoluted ;c)

if so you need easy if an sometimes those if else
ladders are not enough plain imo

(Your "English" is really hard to decipher. - I suggest to use Google
to translate your texts from your native language into something that
is much better understandable and post that translation. - The Google translator is easily accessible from your browser.)

this mean some needs some other construction that should be easier
to read

see for example this code


if(dodge <1.)
{
ÿÿ if(dodge < .5)
ÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿ else if(dodge > .9)
ÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿ else
ÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

ÿÿ return 1;
ÿÿÿÿÿÿÿÿ }

I'd use a function to encapsulate the logging statements; they all
have the same basic structure and you'd avoid all the duplicates.

What I'd do here is:

d=0
if (dodge<1)
d = 3
if (dodge<0.9)
d = 2
if (dodge<0.5)
d = 1

switch (d)
{
case 1:
slog("%s easily dodged attack...", being[k].name);
return 1;
case 2:
slog("%s hardly dodged attack...", being[k].name);
return 1;
case 3:
slog("%s dodged attack...", being[k].name);
return 1;
}

This is pretty easy to read but, it also shows that there are tens of
millions of ways to do this.

// u l i e n


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lane W pisze:

Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

On 05/09/2026 12:43, fir wrote:

imo c in some way is to make programmer not thing liek in assembler >>>>> when you need to hardly mentally focus but you use some plain c
constructions (it is not on all c becouse some c is really
convoluted ;c)

if so you need easy if an sometimes those if else
ladders are not enough plain imo

(Your "English" is really hard to decipher. - I suggest to use Google
to translate your texts from your native language into something that
is much better understandable and post that translation. - The Google
translator is easily accessible from your browser.)

this mean some needs some other construction that should be easier
to read

see for example this code


if(dodge <1.)
{
ÿÿ if(dodge < .5)
ÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿ else if(dodge > .9)
ÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿ else
ÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

ÿÿ return 1;
ÿÿÿÿÿÿÿÿ }

I'd use a function to encapsulate the logging statements; they all
have the same basic structure and you'd avoid all the duplicates.

What I'd do here is:

d=0
if (dodge<1)
ÿÿÿ d = 3
if (dodge<0.9)
ÿÿÿ d = 2
if (dodge<0.5)
ÿÿÿ d = 1

switch (d)
{
ÿÿÿ case 1:
ÿÿÿÿÿÿÿ slog("%s easily dodged attack...",ÿ being[k].name);
ÿÿÿÿÿÿÿ return 1;
ÿÿÿ case 2:
ÿÿÿÿÿÿÿ slog("%s hardly dodged attack...",ÿ being[k].name);
ÿÿÿÿÿÿÿ return 1;
ÿÿÿ case 3:
ÿÿÿÿslog("%s dodgedÿ attack...",ÿ being[k].name);
ÿÿÿÿÿÿÿ return 1;
}

This is pretty easy to read but, it also shows that there are tens of millions of ways to do this.

// u l i e n

and probbaly no one good in c - as you would need

case(d>.9) slog("%s easily dodged attack...", being[k].name);
case(d<.3) slog("%s hardly dodged attack...", being[k].name);
otherwise slog("%s dodged attack...", being[k].name);

all the avaliable now seem worse

from this worse one is (1) two ifs ended with return, second (2) is
if(){} else if (){} else {} - but both are imo somewhat bad

ifs with return need case when you may use return.. if else make reading
of intention convoluted and not proper (coz proper is case case otherwise)






--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-09-05 20:09, Lane W wrote:

[...]

What I'd do here is:

(I wouldn't.)

d=0
if (dodge<1)
ÿÿÿ d = 3
if (dodge<0.9)
ÿÿÿ d = 2
if (dodge<0.5)
ÿÿÿ d = 1

switch (d)
{
ÿÿÿ case 1:
ÿÿÿÿÿÿÿ slog("%s easily dodged attack...",ÿ being[k].name);
ÿÿÿÿÿÿÿ return 1;
ÿÿÿ case 2:
ÿÿÿÿÿÿÿ slog("%s hardly dodged attack...",ÿ being[k].name);
ÿÿÿÿÿÿÿ return 1;
ÿÿÿ case 3:
ÿÿÿÿslog("%s dodgedÿ attack...",ÿ being[k].name);
ÿÿÿÿÿÿÿ return 1;
}

I think this is ignoring a lot of programming principles, even
beyond what had already been suggested in this thread.

This is pretty easy to read but, it also shows that there are tens of millions of ways to do this.

And it isn't, IMO, easy to "read" (i.e. to guarantee consistency,
or easily to maintain; the logic is unnecessarily spread, doubled,
decoupled).


Probably only topped (in negative "quality") by code like this

if (dodge < 1.0) {
slog("%s%s dodged attack...", being[k].name,
" easily\0\0\0\0\0\0\0 hardly"+(int)(dodge*2.2)*7);
return 1;
}

But my ad hoc formula - (int)(dodge*2.2)*7 - needs some tweaking to
exactly match the <0.5 >0.9 conditions; but the ranges seem anyway
to be just rough informal limits so it might "suit" for the purpose.

(Not sure though whether there's UB or anything with that, though,
the '\0' sequence and string addressing looks suspicious at least.
But as a negative example it serves sufficiently well, I think. :-)

Janis


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

On 05/09/2026 12:43, fir wrote:

imo c in some way is to make programmer not thing liek in assembler
when you need to hardly mentally focus but you use some plain c
constructions (it is not on all c becouse some c is really
convoluted ;c)

if so you need easy if an sometimes those if else
ladders are not enough plain imo

(Your "English" is really hard to decipher. - I suggest to use Google
to translate your texts from your native language into something that
is much better understandable and post that translation. - The Google translator is easily accessible from your browser.)

this mean some needs some other construction that should be easier
to read

see for example this code


if(dodge <1.)
{
ÿÿ if(dodge < .5)
ÿÿ{ÿ slog("%s easily dodged attack...",ÿ being[k].name); }
ÿÿ else if(dodge > .9)
ÿÿ{ÿ slog("%s hardly dodged attack...",ÿ being[k].name); }
ÿÿ else
ÿÿÿ slog("%s dodgedÿ attack...",ÿ being[k].name);

ÿÿ return 1;
ÿÿÿÿÿÿÿÿ }

I'd use a function to encapsulate the logging statements; they all
have the same basic structure and you'd avoid all the duplicates.

imo its not readable, switch is also bad here, some needs something
other here soem other if realated construction

As I wrote in some recent post; "I don't think that situation isn't
under control of the individual software writer; you could change
that situation." - Here as well; you have the the possibility to
structure your code. - And while (what you wrote above) "some c is
really convoluted" might be in principle true you seem to expose
some fundamental lack of capability to appropriately structure your
code. (In this case, BTW, a switch to another language with more
structuring options would also not help. Your problem here isn't
primarily or basically a "C" issue.)

It's not the if-else that is the problem here; the example is
dominated by those slog calls.

However your coding style doesn't help, with badly placed and
inconsistent use of braces. The logic here is this:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], name)

(It's beyond me why one would prefer macros to a function here.
But your basic idea to extract the invariant is of course sensible.)

There isn't enough info to see how to write an effective function.

But if 'being[]' and 'name' are locals (or 'k' if 'being' is global),
then the function will need those extra parameters. In that case, the
sdodge calls will not be so different from the original slog calls.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 06/09/2026 01:06, bart wrote:

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], name)

(It's beyond me why one would prefer macros to a function here.
But your basic idea to extract the invariant is of course sensible.)

There isn't enough info to see how to write an effective function.

But if 'being[]' and 'name' are locals (or 'k' if 'being' is global),
then the function will need those extra parameters. In that case, the
sdodge calls will not be so different from the original slog calls.

All we can do is suggest different ideas and ways to arrange such code,
and maybe the OP will see something he feels is a good fit for his
needs. As you say, we are missing a lot of information about the rest
of the code - we don't know what data is "global" or local, when any of
these parts might be re-used, how likely it is that the details or
boundary points will be changed, and countless other details.

In general, I am very sceptical about using macros for this kind of
thing. It is correct that they let you implicitly pass local data into
the macro in a way that functions do not - but that can make the
structure a lot harder to follow, and becomes fragile for changes. So
while it is definitely something that can occasionally be helpful, I
think it is rarely the best solution.

If the OP is happy with compiler extensions, a possibility here is gcc
nested functions - these can capture such local variables in a safer and
more structured manner, keeping the details within the function itself.
(Or he could use C++ and lambdas for a similar effect. There are
proposals to add lambdas to C, but they are not standardised yet.)


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown pisze:

On 06/09/2026 01:06, bart wrote:

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], name)

(It's beyond me why one would prefer macros to a function here.
But your basic idea to extract the invariant is of course sensible.)

There isn't enough info to see how to write an effective function.

But if 'being[]' and 'name' are locals (or 'k' if 'being' is global),
then the function will need those extra parameters. In that case, the
sdodge calls will not be so different from the original slog calls.

All we can do is suggest different ideas and ways to arrange such code,
and maybe the OP will see something he feels is a good fit for his
needs.ÿ As you say, we are missing a lot of information about the rest
of the code - we don't know what data is "global" or local, when any of these parts might be re-used, how likely it is that the details or
boundary points will be changed, and countless other details.

In general, I am very sceptical about using macros for this kind of
thing.ÿ It is correct that they let you implicitly pass local data into
the macro in a way that functions do not - but that can make the
structure a lot harder to follow, and becomes fragile for changes.ÿ So
while it is definitely something that can occasionally be helpful, I
think it is rarely the best solution.

If the OP is happy with compiler extensions, a possibility here is gcc nested functions - these can capture such local variables in a safer and more structured manner, keeping the details within the function itself.
(Or he could use C++ and lambdas for a similar effect.ÿ There are
proposals to add lambdas to C, but they are not standardised yet.)

lol, adding almbdas to c that would be a trash... if the populist will
touch c it would be a heavy disaster (they touched it already too much)

what i strongly need is those long t = 'somethin'; here to this tags
could work up to 8 length (or 16 if some cpu has 128 bit ints)

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 06/09/2026 11:12, fir wrote:

David Brown pisze:

On 06/09/2026 01:06, bart wrote:

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], name) >>>>

(It's beyond me why one would prefer macros to a function here.
But your basic idea to extract the invariant is of course sensible.)

There isn't enough info to see how to write an effective function.

But if 'being[]' and 'name' are locals (or 'k' if 'being' is global),
then the function will need those extra parameters. In that case, the
sdodge calls will not be so different from the original slog calls.

All we can do is suggest different ideas and ways to arrange such
code, and maybe the OP will see something he feels is a good fit for
his needs.ÿ As you say, we are missing a lot of information about the
rest of the code - we don't know what data is "global" or local, when
any of these parts might be re-used, how likely it is that the details
or boundary points will be changed, and countless other details.

In general, I am very sceptical about using macros for this kind of
thing.ÿ It is correct that they let you implicitly pass local data
into the macro in a way that functions do not - but that can make the
structure a lot harder to follow, and becomes fragile for changes.ÿ So
while it is definitely something that can occasionally be helpful, I
think it is rarely the best solution.

If the OP is happy with compiler extensions, a possibility here is gcc
nested functions - these can capture such local variables in a safer
and more structured manner, keeping the details within the function
itself. (Or he could use C++ and lambdas for a similar effect.ÿ There
are proposals to add lambdas to C, but they are not standardised yet.)

lol, adding almbdas to c that would be a trash... if the populist will
touch c it would be a heavy disaster (they touched it already too much)

what i strongly need is those long t = 'somethin'; here to this tags
could work up to 8 lengthÿ (or 16 if some cpu has 128 bit ints)

I used to have both of those (in my language), so I could write 'ABCDEFGHIJKLMNOP' which had an u128 type. I've now dropped 128-bit
types as they were not that useful to me (only for implementing
128-types within the compiler!).

I still have 'ABCDEFGH'.

C however limits such constants to the size of 'int', which is rarely
bigger than 32 bits, so it can only have 'ABCD' (and C itself may only guarantee 'A').

(My C compiler is different, in allowing 'ABCDEFGH'; I think it yields a 64-bit type in this case.)


So, given the current limitations, then what are you suggesting? Are
these just ideas for C extensions, or for a new language?

If you need such features now, then putting these ideas out there is not
going to be of immediate help.

I suggest, if you really need those features soon (this is including the
new 'match' statements), that you write a special preprocessor which
takes programs written in this enhanced C, and generates standard C.

So, 'ABCDEFGH' will be converted to perhaps 0x4847464544434241.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 06/09/2026 13:54, bart wrote:

On 06/09/2026 11:12, fir wrote:

David Brown pisze:

On 06/09/2026 01:06, bart wrote:

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], name) >>>>>

(It's beyond me why one would prefer macros to a function here.
But your basic idea to extract the invariant is of course sensible.)

There isn't enough info to see how to write an effective function.

But if 'being[]' and 'name' are locals (or 'k' if 'being' is
global), then the function will need those extra parameters. In that
case, the sdodge calls will not be so different from the original
slog calls.

All we can do is suggest different ideas and ways to arrange such
code, and maybe the OP will see something he feels is a good fit for
his needs.ÿ As you say, we are missing a lot of information about the
rest of the code - we don't know what data is "global" or local, when
any of these parts might be re-used, how likely it is that the
details or boundary points will be changed, and countless other details. >>>
In general, I am very sceptical about using macros for this kind of
thing.ÿ It is correct that they let you implicitly pass local data
into the macro in a way that functions do not - but that can make the
structure a lot harder to follow, and becomes fragile for changes.
So while it is definitely something that can occasionally be helpful,
I think it is rarely the best solution.

If the OP is happy with compiler extensions, a possibility here is
gcc nested functions - these can capture such local variables in a
safer and more structured manner, keeping the details within the
function itself. (Or he could use C++ and lambdas for a similar
effect.ÿ There are proposals to add lambdas to C, but they are not
standardised yet.)

lol, adding almbdas to c that would be a trash... if the populist will
touch c it would be a heavy disaster (they touched it already too much)

what i strongly need is those long t = 'somethin'; here to this tags
could work up to 8 lengthÿ (or 16 if some cpu has 128 bit ints)

I used to have both of those (in my language), so I could write 'ABCDEFGHIJKLMNOP' which had an u128 type. I've now dropped 128-bit
types as they were not that useful to me (only for implementing 128-
types within the compiler!).

I still have 'ABCDEFGH'.

C however limits such constants to the size of 'int', which is rarely
bigger than 32 bits, so it can only have 'ABCD' (and C itself may only guarantee 'A').

(My C compiler is different, in allowing 'ABCDEFGH'; I think it yields a 64-bit type in this case.)

So, given the current limitations, then what are you suggesting? Are
these just ideas for C extensions, or for a new language?

If you need such features now, then putting these ideas out there is not going to be of immediate help.

I suggest, if you really need those features soon (this is including the
new 'match' statements), that you write a special preprocessor which
takes programs written in this enhanced C, and generates standard C.

So, 'ABCDEFGH' will be converted to perhaps 0x4847464544434241.

I forgot to say that there are various things you can use in standard C,
such as a function, or perhaps a macro, that will convert a string
"ABCDEFGH" to a 64-bit integer. Some care will be needed with "ABCDE"
for example to ensure zero-padding.

You might also look at string interning.

If stuck with a language there are always workarounds! (I prefer purer solutions.)

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

bart pisze:

On 06/09/2026 11:12, fir wrote:

David Brown pisze:

On 06/09/2026 01:06, bart wrote:

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], name) >>>>>

(It's beyond me why one would prefer macros to a function here.
But your basic idea to extract the invariant is of course sensible.)

There isn't enough info to see how to write an effective function.

But if 'being[]' and 'name' are locals (or 'k' if 'being' is
global), then the function will need those extra parameters. In that
case, the sdodge calls will not be so different from the original
slog calls.

All we can do is suggest different ideas and ways to arrange such
code, and maybe the OP will see something he feels is a good fit for
his needs.ÿ As you say, we are missing a lot of information about the
rest of the code - we don't know what data is "global" or local, when
any of these parts might be re-used, how likely it is that the
details or boundary points will be changed, and countless other details. >>>
In general, I am very sceptical about using macros for this kind of
thing.ÿ It is correct that they let you implicitly pass local data
into the macro in a way that functions do not - but that can make the
structure a lot harder to follow, and becomes fragile for changes.
So while it is definitely something that can occasionally be helpful,
I think it is rarely the best solution.

If the OP is happy with compiler extensions, a possibility here is
gcc nested functions - these can capture such local variables in a
safer and more structured manner, keeping the details within the
function itself. (Or he could use C++ and lambdas for a similar
effect.ÿ There are proposals to add lambdas to C, but they are not
standardised yet.)

lol, adding almbdas to c that would be a trash... if the populist will
touch c it would be a heavy disaster (they touched it already too much)

what i strongly need is those long t = 'somethin'; here to this tags
could work up to 8 lengthÿ (or 16 if some cpu has 128 bit ints)

I used to have both of those (in my language), so I could write 'ABCDEFGHIJKLMNOP' which had an u128 type. I've now dropped 128-bit
types as they were not that useful to me (only for implementing
128-types within the compiler!).

I still have 'ABCDEFGH'.

C however limits such constants to the size of 'int', which is rarely
bigger than 32 bits, so it can only have 'ABCD' (and C itself may only guarantee 'A').

(My C compiler is different, in allowing 'ABCDEFGH'; I think it yields a 64-bit type in this case.)

So, given the current limitations, then what are you suggesting? Are
these just ideas for C extensions, or for a new language?

If you need such features now, then putting these ideas out there is not going to be of immediate help.

I suggest, if you really need those features soon (this is including the
new 'match' statements), that you write a special preprocessor which
takes programs written in this enhanced C, and generates standard C.

So, 'ABCDEFGH' will be converted to perhaps 0x4847464544434241.

I STRONGLY NEED IT AND C STRONGLY NEED IT

IT OR YET BETTER SOME GENERALISATION OF IT

i already was writing on it but may repeat

i name it adhoc enum : 'sjhbshj' is an adhoc enum i mean you could
write anyting (though possibly alphanumeric) between '' and compare it
to another ''

if the compiler stores it in ascii or tabelarize it internally its
secondary here

you cald also maybe name this type (which i name adhoc enum)
as a tag type (you may use 2 tyes one is this asci storaged and second
is tabelarized and represented internally as numbers

foo(tag x)
{
if(x=='ala') dosomething();
if(x=='bala') dosomething2();
}


this tags are extremally needed and that i must use four at most is one
of top c annoyances - close to that i dont see declatrations dwn and
must prototype ...and to tahat that "," instead of {} often dont work as
it should, and that i must end lines with ";"

thise mentioned are one of top C anoyances

should probably make list of my top 10 anoyances but lack of tags and
need to predeclare is maybe 2 worst





--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

bart pisze:

On 06/09/2026 13:54, bart wrote:

On 06/09/2026 11:12, fir wrote:

David Brown pisze:

On 06/09/2026 01:06, bart wrote:

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], >>>>>>>> name)

(It's beyond me why one would prefer macros to a function here.
But your basic idea to extract the invariant is of course sensible.) >>>>> There isn't enough info to see how to write an effective function.

But if 'being[]' and 'name' are locals (or 'k' if 'being' is
global), then the function will need those extra parameters. In
that case, the sdodge calls will not be so different from the
original slog calls.

All we can do is suggest different ideas and ways to arrange such
code, and maybe the OP will see something he feels is a good fit for
his needs.ÿ As you say, we are missing a lot of information about
the rest of the code - we don't know what data is "global" or local,
when any of these parts might be re-used, how likely it is that the
details or boundary points will be changed, and countless other
details.

In general, I am very sceptical about using macros for this kind of
thing.ÿ It is correct that they let you implicitly pass local data
into the macro in a way that functions do not - but that can make
the structure a lot harder to follow, and becomes fragile for
changes. So while it is definitely something that can occasionally
be helpful, I think it is rarely the best solution.

If the OP is happy with compiler extensions, a possibility here is
gcc nested functions - these can capture such local variables in a
safer and more structured manner, keeping the details within the
function itself. (Or he could use C++ and lambdas for a similar
effect.ÿ There are proposals to add lambdas to C, but they are not
standardised yet.)

lol, adding almbdas to c that would be a trash... if the populist
will touch c it would be a heavy disaster (they touched it already
too much)

what i strongly need is those long t = 'somethin'; here to this tags
could work up to 8 lengthÿ (or 16 if some cpu has 128 bit ints)

I used to have both of those (in my language), so I could write
'ABCDEFGHIJKLMNOP' which had an u128 type. I've now dropped 128-bit
types as they were not that useful to me (only for implementing 128-
types within the compiler!).

I still have 'ABCDEFGH'.

C however limits such constants to the size of 'int', which is rarely
bigger than 32 bits, so it can only have 'ABCD' (and C itself may only
guarantee 'A').

(My C compiler is different, in allowing 'ABCDEFGH'; I think it yields
a 64-bit type in this case.)


So, given the current limitations, then what are you suggesting? Are
these just ideas for C extensions, or for a new language?

If you need such features now, then putting these ideas out there is
not going to be of immediate help.

I suggest, if you really need those features soon (this is including
the new 'match' statements), that you write a special preprocessor
which takes programs written in this enhanced C, and generates
standard C.

So, 'ABCDEFGH' will be converted to perhaps 0x4847464544434241.

I forgot to say that there are various things you can use in standard C, such as a function, or perhaps a macro, that will convert a string "ABCDEFGH" to a 64-bit integer. Some care will be needed with "ABCDE"
for example to ensure zero-padding.

You might also look at string interning.

If stuck with a language there are always workarounds! (I prefer purer solutions.)

practical ways are probablu

1) use short ones and abbreviations like 'front throw' -> 'fthr'


BAD

2) use two 32 bit tags or 3 ets

t1 ='fron', t2=t th', t3 = 'rov'

BAD

3) use strings

char* tag = "frontthrow";

and use strcomp

BAD

4) use global enum

BAD





--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 06/09/2026 14:25, fir wrote:

bart pisze:

On 06/09/2026 11:12, fir wrote:

David Brown pisze:

On 06/09/2026 01:06, bart wrote:

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], >>>>>>>> name)

(It's beyond me why one would prefer macros to a function here.
But your basic idea to extract the invariant is of course sensible.) >>>>> There isn't enough info to see how to write an effective function.

But if 'being[]' and 'name' are locals (or 'k' if 'being' is
global), then the function will need those extra parameters. In
that case, the sdodge calls will not be so different from the
original slog calls.

All we can do is suggest different ideas and ways to arrange such
code, and maybe the OP will see something he feels is a good fit for
his needs.ÿ As you say, we are missing a lot of information about
the rest of the code - we don't know what data is "global" or local,
when any of these parts might be re-used, how likely it is that the
details or boundary points will be changed, and countless other
details.

In general, I am very sceptical about using macros for this kind of
thing.ÿ It is correct that they let you implicitly pass local data
into the macro in a way that functions do not - but that can make
the structure a lot harder to follow, and becomes fragile for
changes. So while it is definitely something that can occasionally
be helpful, I think it is rarely the best solution.

If the OP is happy with compiler extensions, a possibility here is
gcc nested functions - these can capture such local variables in a
safer and more structured manner, keeping the details within the
function itself. (Or he could use C++ and lambdas for a similar
effect.ÿ There are proposals to add lambdas to C, but they are not
standardised yet.)

lol, adding almbdas to c that would be a trash... if the populist
will touch c it would be a heavy disaster (they touched it already
too much)

what i strongly need is those long t = 'somethin'; here to this tags
could work up to 8 lengthÿ (or 16 if some cpu has 128 bit ints)

I used to have both of those (in my language), so I could write
'ABCDEFGHIJKLMNOP' which had an u128 type. I've now dropped 128-bit
types as they were not that useful to me (only for implementing 128-
types within the compiler!).

I still have 'ABCDEFGH'.

C however limits such constants to the size of 'int', which is rarely
bigger than 32 bits, so it can only have 'ABCD' (and C itself may only
guarantee 'A').

(My C compiler is different, in allowing 'ABCDEFGH'; I think it yields
a 64-bit type in this case.)


So, given the current limitations, then what are you suggesting? Are
these just ideas for C extensions, or for a new language?

If you need such features now, then putting these ideas out there is
not going to be of immediate help.

I suggest, if you really need those features soon (this is including
the new 'match' statements), that you write a special preprocessor
which takes programs written in this enhanced C, and generates
standard C.

So, 'ABCDEFGH' will be converted to perhaps 0x4847464544434241.

I STRONGLY NEED IT AND C STRONGLY NEED IT

IT OR YET BETTER SOME GENERALISATION OF IT

i already was writing on it but may repeat

i name it adhoc enum : 'sjhbshj' is an adhoc enum i mean you could
write anyting (though possibly alphanumeric) between '' and compare it
to another ''

Such enums already exist, but with some restrictions: they must be a
valid C identifier, so no embedded spaces for example:

enum {
sjhbshj,
ala,
bala,
something
};

There is no limit on length, and variables containing such enums don't
need to be 64 or even 32 bits; 8 bits will usually do.

But you also need to list them in advance.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 06/09/2026 14:54, bart wrote:

On 06/09/2026 11:12, fir wrote:

David Brown pisze:

On 06/09/2026 01:06, bart wrote:

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], name) >>>>>

(It's beyond me why one would prefer macros to a function here.
But your basic idea to extract the invariant is of course sensible.)

There isn't enough info to see how to write an effective function.

But if 'being[]' and 'name' are locals (or 'k' if 'being' is
global), then the function will need those extra parameters. In that
case, the sdodge calls will not be so different from the original
slog calls.

All we can do is suggest different ideas and ways to arrange such
code, and maybe the OP will see something he feels is a good fit for
his needs.ÿ As you say, we are missing a lot of information about the
rest of the code - we don't know what data is "global" or local, when
any of these parts might be re-used, how likely it is that the
details or boundary points will be changed, and countless other details. >>>
In general, I am very sceptical about using macros for this kind of
thing.ÿ It is correct that they let you implicitly pass local data
into the macro in a way that functions do not - but that can make the
structure a lot harder to follow, and becomes fragile for changes.
So while it is definitely something that can occasionally be helpful,
I think it is rarely the best solution.

If the OP is happy with compiler extensions, a possibility here is
gcc nested functions - these can capture such local variables in a
safer and more structured manner, keeping the details within the
function itself. (Or he could use C++ and lambdas for a similar
effect.ÿ There are proposals to add lambdas to C, but they are not
standardised yet.)

lol, adding almbdas to c that would be a trash... if the populist will
touch c it would be a heavy disaster (they touched it already too much)

what i strongly need is those long t = 'somethin'; here to this tags
could work up to 8 lengthÿ (or 16 if some cpu has 128 bit ints)

I used to have both of those (in my language), so I could write 'ABCDEFGHIJKLMNOP' which had an u128 type. I've now dropped 128-bit
types as they were not that useful to me (only for implementing 128-
types within the compiler!).

I still have 'ABCDEFGH'.

C however limits such constants to the size of 'int', which is rarely
bigger than 32 bits, so it can only have 'ABCD' (and C itself may only guarantee 'A').

(My C compiler is different, in allowing 'ABCDEFGH'; I think it yields a 64-bit type in this case.)

So, given the current limitations, then what are you suggesting? Are
these just ideas for C extensions, or for a new language?

Note - an appropriate "new" language exists here. With C++, you can
make a user-defined literal so that "ABCDEFGH"_tag would evaluate, at compile-time (no run-time overhead) to a 64-bit tag number. Or maybe a 128-bit number if you want, or a 32-bit hash, or whatever you like.

If you need such features now, then putting these ideas out there is not going to be of immediate help.

I suggest, if you really need those features soon (this is including the
new 'match' statements), that you write a special preprocessor which
takes programs written in this enhanced C, and generates standard C.

I've used custom utilities for such things. The most convenient way is
not to try to implement a custom pre-processor, but to just to generate
a header file. So you might use "$$(ABCDEF)" in the source code
"file.c". That file #include's a file called "file.hash.h", which is generated by a script that reads "file.c" and for each usage of a $$
macro, has a line like "#define $$_ABCDEF 123456" (or whatever the hash
value is). It ends with "#define $$(XX) $$ ## XX". A couple of
makefile rules later, and you have your build-time hash function with
just a simple utility in a dozen lines of Python code.

Still, it's much easier in C++, so I haven't done this for years.

So, 'ABCDEFGH' will be converted to perhaps 0x4847464544434241.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)