Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #143188
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c, comp.lang.c++ |
| Subject | Re: for ... else blocks |
| Date | 2019-04-17 20:43 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <87lg084du9.fsf@bsb.me.uk> (permalink) |
| References | (3 earlier) <q95fqk$94s$1@dont-email.me> <q95hsl$kuq$1@dont-email.me> <q95ltu$c8r$1@dont-email.me> <87y3494hru.fsf@bsb.me.uk> <q963vs$ck8$1@dont-email.me> |
Cross-posted to 2 groups.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
<cut>
> 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.
Yes. VALOF $( ... RESULTIS exp ... $) to be precise, with later
versions permitting { } in place of $( $). And of course gcc has
statement expressions as an extension, though you can't "return" from
them at arbitrary points -- the last expression is the 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.
> }
This is not the example I had, so the bool is not well named as it is
not always set true when the loop body executes.
I can't think of a neat way to avoid using the flag variable, even
using BCPL-style VALOF:
IF NOT VALOF $(
LET loop_body_executed = FALSE
FOR N = 1 TO MAX DO $(
code; code; loop_body_executed := TRUE
$)
RESULTIS loop_body_executed
$) DO $(
// original else part
$)
But there's a bigger problem with both this and the lambda version:
neither abstracts over the loop code. You write it fresh each time.
And you can't even cut and paste the loop code because 'break's have to
turn into 'return true'.
In Lisp you could write a macro for both meanings where the user simply
has to supply the loop code and the 'else' code.
> 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
This seems to be getting close to what I'd call lambda abuse. Is it
worth it to avoid the () that you'd otherwise need? I realise I may be
missing the point, though.
<cut>
--
Ben.
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