Re: else ladders practice

On 01/11/2024 19:05, Bart wrote:

On 01/11/2024 17:35, David Brown wrote:

On 01/11/2024 16:59, Bart wrote:

On 01/11/2024 14:17, fir wrote:

fir wrote:

Bart wrote:

On 01/11/2024 12:55, fir wrote:

Bart wrote:

On 01/11/2024 11:32, fir wrote:

Bart wrote:

ral clear patterns here: you're testing the same variable 'n' against
several mutually exclusive alternatives, which also happen to be
consecutive values.
>
C is short of ways to express this, if you want to keep those
'somethings' as inline code (otherwise arrays of function pointers or
even label pointers could be use

>
so in short this groupo seem to have no conclusion but is tolerant
foir various approaches as it seems
>
imo the else latder is like most proper but i dont lkie it optically,
swich case i also dont like (use as far i i remember never in my code,
for years dont use even one)
>
so i persnally would use bare ifs and maybe elses ocasionally
(and switch should be mended but its fully not clear how,
>
as to those pointer tables im not sure but im like measurad it onece
and it was (not sure as to thsi as i dont remember exactly) slow maybe
dependant on architecture so its noth wort of use (if i remember
correctly)

>
Well, personally I don't like that repetition, that's why I mentioned
the patterns. You're writing 'n' 5 times, '==' 5 times, and you're
writing out the numbers 1, 2, 3, 4, 5.
>
I also don't like the lack of exclusivity.
>
However I don't need to use C. If those 'somethings' were simple, or
were expressions, I could use syntax like this:
>
    (n | s1, s2, s3, s4, s5)
>

>
on a C ground more suitable is
>
{s1,s2,s3,s4,s5)[n]
>
//which is just array indexing

>
No, it's specifically not array indexing, as only one of s1 - s5 is
evaluated, or nothing is when n is not in range, eg. n is 100.
>
You could try something like that in C:
>
     int x;
>
     x = ((int[]){(puts("a"),10), (puts("b"),20), (puts("c"), 30),
(puts("d"),40)})[3];
>
     printf("X=%d\n", x);
>
The output is:
>
    a
    b
    c
    d
    X=40
>
Showing that all elements are evaluated first. If index is 100, the
result is also undefined.
>
>

:-O
what is this, first time i see such thing
>

im surprised that it work, but in fact i meant that this syntax is old c compatible but sych thing like
>
>
{printf("ONE"), printf("TWO"), printf("THREE")} [2]
>
shouldn evaluate al just the one is selected
like in array tab[23] not eveluates something other than tab[23]

>
It's a 'compound literal'. It allows you to have the same {...} initialisation data format, but anywhere, not just for initialing. However it always needs a cast:
>
   (int[]){printf("ONE"), printf("TWO"), printf("THREE")}[2];
>
This prints ONETWOTHREE, it also then indexes the 3rd value of the array, which is 5, as returned by printf, so this:
>
   printf("%d\n", (int[]){printf("ONE"), printf("TWO"), printf("THREE")}[2]);
>
   prints ONETWOTHREE5
>
>

>
What you have written here is all correct, but a more common method would be to avoid having three printf's :
>
void shout_a_number(int n) {
     printf( (const char* []) { "ONE", "TWO", "THREE" } [n] );
}
>
That's more likely to match what people would want.

 I was also trying to show that all elements are evaluated, so each has to have some side-effect to illustrate that.

Fair enough.

 A true N-way-select construct (C only really has ?:) would evaluate only one, and would deal with an out-of-range condition.

That's a matter of opinion and design choice, rather than being requirements for a "true" select construct.  You are free to choose the rules you want for your own language, but you are not free to dictate what you think the rules should be for others.  (You are welcome to /opinions/, of course.)

 (In my implementations, a default/else branch value must be provided if the whole thing is expected to return a value.)
 

OK, if that's what you want.  My preference, if I were putting together what /I/ thought was an idea language for /my/ use, would be heavy use of explicit specifications and contracts for code, so that a default/else branch is either disallowed (if there the selection covers all legal values) or required (if the selection is abbreviated).  A default value "just in case" is, IMHO, worse than useless.
Different people, different preferences.