Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Fri, 1 Nov 2024 09:56:56 +0100
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <vg254o$3652k$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <20241031161545.aed6541ce6c728923a46e9df@g{oogle}mail.com>
 <vg0hhn$2psrf$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 01 Nov 2024 09:56:57 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c165984b9aabe98dd56dee5418bcc391";
	logging-data="3347540"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/oqjBkaqql2oYIzjl+RzF8rn60fCGwujI="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:xbj6cZDwogUDJlAsxxXONzPMqRM=
Content-Language: en-GB
In-Reply-To: <vg0hhn$2psrf$1@dont-email.me>
Bytes: 4419

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.