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@yahoo.fr
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