Deutsch English Français Italiano |
<vgdfhs$1jefc$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: Tue, 5 Nov 2024 17:02:04 +0100 Organization: A noiseless patient Spider Lines: 39 Message-ID: <vgdfhs$1jefc$1@dont-email.me> References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org> <vg2g37$37mh3$1@dont-email.me> <6724CFD2.4030607@grunge.pl> <vg2llt$38ons$1@dont-email.me> <2491a699388b5891a49ef960e1ad8bb689fdc2ed@i2pn2.org> <b681ee05856e165c26a5c29bf42a8d9d53843d6d@i2pn2.org> <vg2ttn$3a4lk$1@dont-email.me> <vg33gs$3b8n5$1@dont-email.me> <vg358c$3bk7t$1@dont-email.me> <vg37nr$3bo0c$1@dont-email.me> <vg3b98$3cc8q$1@dont-email.me> <vg5351$3pada$1@dont-email.me> <vg62vg$3uv02$1@dont-email.me> <vgd3ro$2pvl4$1@paganini.bofh.team> <vgdc4q$1ikja$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 05 Nov 2024 17:02:04 +0100 (CET) Injection-Info: dont-email.me; posting-host="57a2613ac94f24808de446d87ca9a407"; logging-data="1685996"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18KDD3gPKdjnUPMIiA3ws6veJSlJYGpWGE=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cancel-Lock: sha1:5vTlILrecM/lLXGb8FyKDh+3nNM= In-Reply-To: <vgdc4q$1ikja$1@dont-email.me> Content-Language: en-GB Bytes: 3325 On 05/11/2024 16:03, Bart wrote: > On 05/11/2024 12:42, Waldek Hebisch wrote: >> Bart <bc@freeuk.com> wrote: >>> >>> Then we disagree on what 'multi-way' select might mean. I think it means >>> branching, even if notionally, on one-of-N possible code paths. >> >> OK. >>> The whole construct may or may not return a value. If it does, then one >>> of the N paths must be a default path. >> >> >> You need to cover all input values. This is possible when there >> is reasonably small number of possibilities. For example, switch on >> char variable which covers all possible values does not need default >> path. Default is needed only when number of possibilities is too >> large to explicitely give all of them. And some languages allow >> ranges, so that you may be able to cover all values with small >> number of ranges. >> > > What's easier to implement in a language: to have a conditional need for > an 'else' branch, which is dependent on the compiler performing some > arbitrarily complex levels of analysis on some arbitrarily complex set > of expressions... > > ...or to just always require 'else', with a dummy value if necessary? If this was a discussion on learning about compiler design for newbies, that might be a relevant point. Otherwise, what is easier to implement in a language tool is completely irrelevant to what is good in a language. A language should try to support things that are good for the /programmer/, not the compiler. But it does have to limited by what is practically possible for a compiler. A fair bit of the weaknesses of C as a language can be attributed to the limitations of compilers from its early days, and thereafter existing practice was hard to change.