- Nested (not early exit) returns - 2 Updates
- My Parallel archiver version 3.4 is here... - 1 Update
- Nested (not early exit) returns - 4 Updates
| ram@zedat.fu-berlin.de (Stefan Ram): Jul 08 02:30AM >return *result.pointer_to<Key_event>(); First observation: This function has a return within a loop, but only a single exit point, which is this return. It never exits via its final brace. So it already is SESE, and we just have to care about the other function preceding it. |
| bleachbot <bleachbot@httrack.com>: Jul 08 08:54PM +0200 |
| Ramine <ramine@1.1>: Jul 08 02:54PM -0400 Hello, My Parallel archiver version 3.4 is here... This new version was enhanced more, and here is what i have added: - Now it supports processor groups on windows, so that it can use more than 64 logical processors and it scales well. - It's now NUMA-aware and NUMA efficient. - Now it minimizes efficiently the contention so that it scales well. And i have added a fourth parameter to the constructor, it is the boolean parameter that is processorgroups to support processor groups on windows , if it is set to true it will enable you to scale beyond 64 logical processors and it will be NUMA efficient. I have thoroughly tested and stabilized my parallel archiver for many years, and now i think that it is more stable and efficient, so you can be more confident with it. You can download the new version 3.4 from: https://sites.google.com/site/aminer68/parallel-archiver Thank you, Amine Moulay Ramdane. |
| bartekltg <bartekltg@gmail.com>: Jul 08 02:07AM +0200 On 07.07.2016 18:09, Alf P. Steinbach wrote: > return false; > } > } What is a relation between has_event and event? If both properties are independent, ***** bool had_key = false; while (all_events_.has<Event>()) { if( all_events_.has<Key_event>() ){ had_ket=true; break; } all_events_.next_event(); } if (had_key) return true; else // key not found, not a Event return all_events_.has<Key_event>() ***** I do not think this is better than original. Or, if all_events_.has<Key_event>() is fast: ***** while (all_events_.has<Event>()) { if( all_events_.has<Key_event>() ) break; all_events_.next_event(); } return all_events_.has<Key_event>() ***** The compiler may optimize it and get rid of the second call. If one exclude the other ***** while (all_events_.has<Event>()) all_events_.next_event(); return all_events_.has<Key_event>() ***** bartekltg |
| "Öö Tiib" <ootiib@hot.ee>: Jul 07 11:43PM -0700 On Thursday, 7 July 2016 19:11:37 UTC+3, Alf P. Steinbach wrote: > I think this code is just fine, nothing particularly wrong, but I'm > concerned I've changed into a mindset where I think so because I don't > /see/ how wonderfully clearly it could be expressed otherwise? Shorter and SESE (and clear IMHO) but some coding standards forbid assignment in boolean expressions: auto has_event() const -> bool { bool ret; while( !(ret = all_events_.has<Key_event>()) && all_events_.has<Event>() ) { all_events_.next_event(); // Consume non-key event. } return ret; } |
| David Brown <david.brown@hesbynett.no>: Jul 08 10:31AM +0200 On 07/07/16 18:09, Alf P. Steinbach wrote: > see things very differently, and I can't recall how I then thought. > Is there some natural non-`return` way to code this that isn't > needlessly complex or inefficient, perhaps even better in some way? Remind me what group this is, and what language we are using here? C++ left the "SESE" idea behind when exceptions were introduced, and the whole RAII concept is what turns multiple exits from a risky strategy into a safe one. Every possible exception is not only an extra exit to the function, but it is a hidden and undocumented one - yet I am sure you are happy to use exceptions in your code. A key argument against multiple exits in a function is the risk of leaking resources or leaving your data structures inconsistent when exiting before any necessary clean-up (or having to duplicate said clean-up code). With RAII and synchronous destructors, this is a non-issue in well-written C++ code. The other argument against multiple exits is that it can make it hard to see the code flow. It is simply a matter of writing your code in a way that makes the code flow clear - and often multiple exits can do that much more clearly than "SESE" workarounds. Certainly I find your code with multiple returns /far/ clearer than Öö's version with assignment in boolean expressions, and multiple function calls within an && expression. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 08 11:16AM +0200 On 08.07.2016 08:43, Öö Tiib wrote: > } > return ret; > } Thanks! I don't think this is maximally clear (presently I have to /decode/ it in my mind) but I think this way of thinking is precisely what I was hunting for. It would be a shame if I overlooked something by not even considering this kind of approach, due to getting blind in certain directions in my mind's eye. 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