- for ... else blocks - 4 Updates
| David Brown <david.brown@hesbynett.no>: Apr 16 11:36PM +0200 On 16/04/2019 23:02, Rick C. Hodgin wrote: >> Do you have any actual use-cases for this? > I came across a need for it today in my code, which is why / how it > occurred to me. I think you'll need to show some concrete examples in order to show the point. At the moment, I'm left thinking that you are constructing complicated syntax for the programmer to write things that a compiler can handle already using simple C syntax and some optimisations. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 16 02:57PM -0400 I'm curious what people's thought are on this idea. It allows the initial test on the for {..} block to enter the block, or fall-through to the else clause. Subsequent tests on the for {..} block that fail simply exit out past the last }. for (init; test; incr) { // for code here } else { // else code here } It's the equivalent of: init; if (test) { goto skip_first_iteration; for ( ; test; incr) { skip_first_iteration: // for code here } } else { // else code here } Seems a natural progression. One I could use quite often due to the need to test the conditions outside of the for {..} block today before entering it with then-known valid data. If the test for a valid state could be incorporated into the generic iterative test, and the else clause added, it would be more natural methinks. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 16 03:06PM -0400 On 4/16/2019 2:57 PM, Rick C. Hodgin wrote: > for ( ; test; incr) > { > skip_first_iteration: Should be "skip_first_test:". > entering it with then-known valid data. If the test for a valid state > could be incorporated into the generic iterative test, and the else > clause added, it would be more natural methinks. Another variant could be: for_if (test1; init; test2; incr) { } else { } test1 is the if (test1) test, and if it fails, goes to the else. The test2 is the iterative test which processes like normal. This one could be used when test1 and test2 are different, or are not overlapping. Of course "else if" blocks could also be used, and I think also a new concept of "else for" block could also be used: for (init1; test1; incr1) { // First for code here } else for (init2; test2; incr2) { // Second for code here } else for (init3; test3; incr3) { // Third for code here } else { // Fallthrough code } Same for: for_if (test1_1; init1; test1_2; incr1) { // First for_if code here } else for_if (test1_1; init1; test1_2; incr1) { // Second for_if code here } else for_if (test1_1; init1; test1_2; incr1) { // Third for_if code here } else { // Fallthrough code } And, of course, for {..} and for_if {..} blocks could be intermixed. -- Rick C. Hodgin |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 17 12:45AM +0200 On 16.04.2019 23:36, David Brown wrote: > At the moment, I'm left thinking that you are constructing complicated > syntax for the programmer to write things that a compiler can handle > already using simple C syntax and some optimisations. 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. } It can also be expressed with all code inline in current func with exceptions. The `return false` then corresponds to throwing of an exception. I believe that's how the construct works in CPython. The exception based logic would look more clean but potentially carries some execution overhead for the "else" case. Cheers!, - Alf |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment