Deutsch English Français Italiano |
<vg254o$3652k$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
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.