Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #143158
| From | "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c, comp.lang.c++ |
| Subject | Re: for ... else blocks |
| Date | 2019-04-17 04:45 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <q963vs$ck8$1@dont-email.me> (permalink) |
| References | (2 earlier) <z8qtE.88600$SH1.74138@fx03.am4> <q95fqk$94s$1@dont-email.me> <q95hsl$kuq$1@dont-email.me> <q95ltu$c8r$1@dont-email.me> <87y3494hru.fsf@bsb.me.uk> |
Cross-posted to 2 groups.
On 17.04.2019 02:06, Ben Bacarisse wrote:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>
>> I don't see Rick's postings, but I imagine what he wants is a
>> construct for this (note: I think it indicates the lambda should be a
>> named func):
>>
>> const bool early_loop_exit = invoke( [&]() -> bool
>> {
>> for( INIT; COND; UPDATE )
>> {
>> if( SOMETHING ) { return true; }
>> }
>> return false;
>> } );
>>
>> if( not early_loop_exit )
>> {
>> // The logical "else" part.
>> }
>
> That looks like the Python meaning, not the one RCH was suggesting. I
> think RCH's intent can be written as:
>
> bool loop_body_executed = false;
> for (INIT; COND; UPDATE, loop_body_executed = true) {
> // ...
> }
> if (!loop_body_executed) {
> // The logical "else" part.
> }
>
Thanks. That seems to indicate that there are at least two about equally
convincing but exactly opposite notions of what `else` should mean if it
were introduced as an extension to `for`...
---
Anyway I find your example interesting because it's easier to read, and
therefore grok, than my example that, more ideally, constrains the scope
for modification of the variable.
And I think that's due to two reasons:
• That your example is shorter, mainly because of formatting.
• That C++, from its C heritage, supports the changing-variables style
of coding, and does not so much support expression based coding.
In some other contexts the shorter formatting tends to produce what in
my eyes is a gray wall of compact code, so I'm wary of adopting it. It's
nice for books and articles, though, where vertical space is a limited
resource. But on the third and gripping hand I may be too old to change
formatting preferences again...
---
Going back even further historically, C's parent language BCPL had a
construct that one can think of as “arithmetic blocks”, like a curly
braces compound statement that could return a value.
And expressing your example with an imaginary such construct it's not
significantly more to read, and then properly constrains the scope where
the code can change or influence the value of the boolean:
const bool loop_body_executed = BCPL_BLOCK {
for (INIT; COND; UPDATE) {
if( SOMETHING ) { return true; }
}
return false;
};
if( not loop_body_executed ) {
// The logical "else" part.
}
---
As it happens it's easy to define a macro like BCPL_BLOCK:
#define BCPL_BLOCK ~[&]()
... where the `~` operator is defined as e.g.
namespace lambda_support
{
using std::declval;
template< class Func
, class Enabled_ = decltype( declval<Func>()() )
>
inline auto operator~( Func const& f )
-> decltype(( f() ))
{ return f(); }
} // namespace lambda_support
One just needs a `using` statement for it. Hence the need for SFINAE to
ensure that this definition only kicks in, that it's only found, when
`~` is applied to something callable without arguments. It should
probably be even more constrained than what I managed above.
So, that notation is not hypothetical. It's also easy to provide
bindings for the lambda, e.g. using the `%` operator. It would be (or
was when I tried it out, some years ago, then named `$invoked_with`
instead of BCPL_BLOCK) a rather ugly hack that didn't entirely prevent
incorrect use, but if one could get language and/or standard library
support then it could be safe, because the standard library is allowed
to use magic. I'd prefer a core language prefix invocation operator.
Cheers!,
- Alf
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