Nested (not early exit) returns

[Alf P. Steinbach]

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?

I remember discussing SESE/SEME with Andrei Alexandrescu over in clc++m
once, where I insisted on SESE being more clear and less error prone.
That view was, I now think, very much colored by experience maintaining
some ugly C code with umpteen-hundred line functions. But anyway I now
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?

class Key_event_stream
: public Non_copyable
, public Non_movable
{
private:
Ref_<Event_stream> all_events_ = Event_stream::singleton();

~Key_event_stream() {}

public:
auto has_event() const
-> bool
{
for( ;; )
{
if( all_events_.has<Key_event>() )
{
return true;
}
else if( all_events_.has<Event>() )
{
all_events_.next_event(); // Consume non-key event.
}
else
{
return false;
}
}
}

auto next_event()
-> Key_event
{
for( ;; )
{
Boxed_event result{ all_events_.next_event() };
if( result.pointer_to<Key_event>() != nullptr )
{
return *result.pointer_to<Key_event>();
}
}
}

static auto singleton()
-> Ref_<Key_event_stream>
{
static Key_event_stream the_instance;
return the_instance;
}
};

Cheers!,

- Alf

[Alf P. Steinbach]

On 07.07.2016 18:09, Alf P. Steinbach wrote:
> I think this code is just fine, nothing particularly wrong, but I'm

Oh yes, the `if` can be simplified I see just after posting.

Sorry 'bout that, :)

- Alf

[K. Frank]

Hello Alf!

On Thursday, July 7, 2016 at 12:11:37 PM UTC-4, Alf P. Steinbach wrote:
> ...
> I remember discussing SESE/SEME with Andrei Alexandrescu ...

All this talk of SESE/SEME reminds me of fortran with its
support for multiple entry points into the same subroutine.

> Cheers!,
>
> - Alf


Cheerio!


K. Frank

[bartekltg]

On 07.07.2016 18:09, Alf P. Steinbach wrote:

> for( ;; )
> {
> if( all_events_.has<Key_event>() )
> {
> return true;
> }
> else if( all_events_.has<Event>() )
> {
> all_events_.next_event(); // Consume non-key event.
> }
> else
> {
> 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]

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]

On 07/07/16 18:09, 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?
>
> I remember discussing SESE/SEME with Andrei Alexandrescu over in clc++m
> once, where I insisted on SESE being more clear and less error prone.
> That view was, I now think, very much colored by experience maintaining
> some ugly C code with umpteen-hundred line functions. But anyway I now
> 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]

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