Re: else ladders practice

On 31/10/2024 19:16, James Kuyper wrote:

On 10/31/24 09:15, Anton Shepelev wrote:

fir:
>

somethins i got such pies of code like
>
if(n==1) {/*something/}
if(n==2) {/*something/}
if(n==3) {/*something/}
if(n==4) {/*something/}
if(n==5) {/*something/}
>
technically i would need to add elses

>
Why?

 He has indicated that the value of n is not changed inside any of the
if-clauses. A sufficiently sophisticated compiler could notice that
fact, and also that each of the conditions is on the same variable, and
as a result it could generate the same kind of code as if it had been
written with 'else', so it won't generate unnecessary condition tests.
It might, in fact, generate the same kind of code which would have been
generated if it had been coded properly, as a switch statement, so it
might use a jump table, if appropriate.
But it's better to write it as a switch statement in the first place, so
you don't have to rely upon the compiler being sufficiently
sophisticated to get the best results.

I disagree entirely.
It is best to write the code in the way that makes most sense - whatever gives the best clarity and makes the programmer's intentions obvious to readers, and with the least risk of errors.  Consider the maintainability of the code - is it likely to be changed in the future, or adapted and re-used in other contexts?  If so, that should be a big influence on how you structure the source code.  Can a different structure make it less likely for errors to occur unnoticed?  For example, if the controlling value can be an enumeration then with a switch, a good compiler can check if there are accidentally unhandled cases (and even a poor compiler can check for duplicates).
But details of the efficiency of the generated object code, especially on weaker compilers, should not be a consideration unless you have measured the speed of the code, found it slower than the requirements, and identified the code section that can be made significantly more efficient by re-structuring.
I would rather say that you /should/ rely on the compiler being sophisticated, if code speed is important to your task.  Let the compiler handle the little things, so that the programmer can concentrate on the big things - clear code, correct code, maintainable code, low-risk code, and efficient /algorithms/.
I am sure you would not advocate for using #define'd constants instead of "const" values, or function-like macros instead of inline functions, or goto's instead of "for" loops, or re-using a "register int temp1;" variable defined at the top of a function instead of block-local appropriately named variables.  All these things can give more efficient results on weak compilers - but all are detrimental to code quality, and that's what you should put first.
In practice, I probably /would/ structure the code as a switch rather than a series of "if" statements, unless I had overriding reason to do otherwise.  But /not/ because of efficiency of the results.
Without all the details of the OP's code, it is of course impossible to be sure what structure is clearest for his code.