Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #143177
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c, comp.lang.c++ |
| Subject | Re: for ... else blocks |
| Date | 2019-04-17 17:51 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <q97i2u$p2b$1@dont-email.me> (permalink) |
| References | (9 earlier) <kmDtE.71610$da5.23289@fx13.am4> <q974qd$a1$1@dont-email.me> <AoFtE.111551$sX.36190@fx31.am4> <q97a4r$35u$1@dont-email.me> <tzGtE.434583$%SF.74131@fx15.am4> |
Cross-posted to 2 groups.
On 17/04/2019 16:16, Bart wrote:
> On 17/04/2019 14:36, David Brown wrote:
>> On 17/04/2019 14:57, Bart wrote:
>
>>> By higher level I mean something like:
>>>
>>> do_option(name in optionnames, value)
>>>
>>> 'in' would return 1..len or 0, so do_option would have to deal with a
>>> option code of 0, to keep it simple.
>>>
>>
>> That is an odd construct - I would not expect to see it, or immediately
>> know what was meant.
>
> Python has "in" but just returns True or False, which is not very
> helpful. My version returns the index where a occurs in b, although most
> useful for 1-based lists.
>
> I would rather expect something like:
>>
>> if (name in optionnames) {
>> do_option(optionnames[name], value);
>
> You're doing a double lookup, one with "in", and one with [], which
> latter would require optionnames to be a dict. It gets messy.
>
Depending on the data structure, the double lookup would often be fast
and simple. In a compiled language with an optimising compiler,
especially in a language which emphasises immutable data (as most modern
languages do), this could be optimised.
However, this is just sample code in an imaginary language - not
something we need to figure out in detail.
>
>> I don't disagree that a "for ... else ..." clause could be useful. But
>> I am not convinced that it is useful enough to overcome potential
>> confusion - I think its use would be rare, and alternative simple and
>> clear solutions are easily available.
>
> It's rare partly because languages don't have it!
>
Mostly it is rare because you don't usually need it.
> Although I already said it would have problems being added to C because
> of the ambiguity of 'else'.
>
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
for ... else blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-16 14:57 -0400
Re: for ... else blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-16 15:06 -0400
Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-16 20:35 +0100
Re: for ... else blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-16 17:02 -0400
Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-16 23:36 +0200
Re: for ... else blocks "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-04-17 00:45 +0200
Re: for ... else blocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-17 01:06 +0100
Re: for ... else blocks "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-04-17 04:45 +0200
Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-17 09:32 +0200
Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-17 11:38 +0100
Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-17 14:05 +0200
Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-17 13:57 +0100
Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-17 15:36 +0200
Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-17 15:16 +0100
Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-17 17:51 +0200
Re: for ... else blocks "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-04-17 16:15 +0200
Re: for ... else blocks "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-04-17 16:24 +0200
Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-17 17:55 +0200
Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-17 17:44 +0100
Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-17 17:48 +0100
Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 10:18 -0700
Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 10:32 -0700
Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 10:38 -0700
Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 12:12 -0700
Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 12:25 -0700
Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 12:39 -0700
Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 15:52 -0700
Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 16:50 -0700
Re: for ... else blocks fir <profesor.fir@gmail.com> - 2019-04-17 13:58 -0700
Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-18 12:21 +0200
Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-18 18:54 +0100
Re: for ... else blocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-18 20:36 +0100
Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-18 21:15 +0100
Re: for ... else blocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-18 21:46 +0100
Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-17 15:05 +0100
Re: for ... else blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-17 10:55 -0400
Re: for ... else blocks Ike Naar <ike@iceland.freeshell.org> - 2019-04-18 05:57 +0000
Re: for ... else blocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-17 20:43 +0100
Re: for ... else blocks Chad <cdalten@gmail.com> - 2019-04-16 12:15 -0700
Re: for ... else blocks Bart <bc@freeuk.com> - 2019-04-16 20:27 +0100
Re: for ... else blocks Christian Gollwitzer <auriocus@gmx.de> - 2019-04-16 21:34 +0200
Re: for ... else blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-16 16:54 -0400
Re: for ... else blocks David Brown <david.brown@hesbynett.no> - 2019-04-16 23:32 +0200
csiph-web