Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?

Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-09-08 19:40:29

I have skimmed this thread and wanted to offer my opinion.

I do not see code like the OP has provided in what I write, so to me this is
a solution looking for a problem. Like most, I prefer small blocks of code
with simple patterns such as:

type method(args)
{
    if (cond(args))
       return foo(args);
    intermediate val = calc(args);
    return result(val, args);
}

The case for 'Breakable' seems to be to support a code style that is, pardon
me, quite archaic. As has been noted in this thread, if the code was written
to be modular and self-documenting to start with, there is no need for
'breakable'.

It really is just a way of inlining an anonymous half-function, with
implicit arguments and an implicit return type. Contrary to the authors
claims, I do not see this as a mechanism for producing better or more
readable code.

At the end of the day, it is about style and for that reason I do not think
it is a good candidate for inclusion into boost. I too second the idea of
perhaps extending Boost.ScopedExit, which I personally have used to create
strong exception-safe code without having to make a dozen auxiliary CIRA
structures.

'Breakable' is a way to create long methods, or dealing with many nested
conditionals. These are not needed in the first place. If you are at greater
than 2 levels of indentation, that is a sign that you need to refactor, not
a sign that you need to make the function 'Breakable'.

Regards,
Christian.

On Wed, Sep 9, 2009 at 9:30 AM, Pierre Morcello <pmorcell-cppfrance_at_[hidden]
> wrote:

> At Stewart Roberts, about "embedded if else" vs "Breakable idiom".
>
> (I answer in a separated mail, because this may also interest other people,
> more than the previous one).
>
>
> You proposed the "embedded if{}else{}" solution. If I was fully pleased
> with it, I would not have dare to propose the 'Breakable' idiom solution
> :-). My
> concerns are :
>
> 1
>
> When you are embedding if/ else, you got quickly more tabs/space to manage.
>
>
> 2
>
> When you are embedding more than 4 if/else, you have to be more careful
> to the right side of your line. Nobody like to scroll left right, and
> it is harder to print or display on your website ^^. Even more if you
> got a 10' screen.
>
>
> 3
>
> When you are using the 'Breakable' idiom, your code is vertically
> structured, and looking extremely homogeneous.
>
>
> 4
>
> With the 'Breakable' idiom, 'else' is implicit. As a consequence, you
> will have less lines (unless you are using "}else{" like unix user, in
> which case it is the same length).
>
>
> 5 The "test", "fail case" and the "ok case" looks more contiguous. These
> are not
> separated by the other tests or the "}else{". There are less "visuals
> parasite" between them.
>
>
>
> Have a look :
>
> if(t1)
>
> {
>
>       if(t2)
>
>       {
>
>             if(t3)
>
>             {
>
>                   if(t4)
>
>                   {
>
>                         if(t4)
>
>                         {
>
>                         }
>
>                         else
>
>                         {
>
>                         }
>
>                   }
>
>                   else
>
>                   {
>
>                   }
>
>             }
>
>             else
>
>             {
>
>             }
>
>       }
>
>       else
>
>       {
>
>       }
>
> }
>
> else
>
> {
>
> }
>
>
>
> Breakable
>
> {
>
>       if(!t1)
>
>       {
>
>             break;
>
>       }
>
>       if(!t2)
>
>       {
>
>             break;
>
>       }
>
>       if(!t3)
>
>       {
>
>             break;
>
>       }
>
>       if(!t4)
>
>       {
>
>             break;
>
>       }
>
>       if(!t5)
>
>       {
>
>             break;
>
>       }
>
> }
>
> You can also imagine 1 or 2 lines of code between each test and case, to
> get an idea of the use.
>
>
> 6
>
> The breakable code is easier to maintain : you can add a test and a
> else without "re-tabbing" the code, and also without needing to scroll
> up/down to make the
> visual correspondance between a "if " and a "else" that are separated by 4
> tests.
>
>
>
> As a consequence, I consider The 'Breakable idiom' often improves
> readability for theses tasks, over the embedded if{}else{}.
>
> Also, compared to the expanded version (for(bool executed=false;
> executed!=true; executed =true) or do{...}while(false), the 'Breakable
> macro'
> tells why it is here : it suppresses doubts. I suppose most of my
> coworker would ask me why there is a "do{...}while(false)" in some code,
> while on
> the contrary, it took them no pain to understand the use and the meaning
> (when they read it in someone else code) of the macro.
>
> Thanks for your time,
>
>
> Best regards,
>
>
>
> Pierre Morcello
>
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>