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

Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?
From: Ilya Bobir (ilya.bobir_at_[hidden])
Date: 2009-09-08 21:51:45

Christian Schladetsch wrote:
> 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.

It is not very common but sometimes logical structure of a function can 
be expressed more precisely using a control flow statement similar to 
this breakable thing.  As Gottlob Frege has pointed out this kind of 
logic sometimes occur in Windows GUI programming.  It seems to me that 
DirectX API at least in some old versions also tend to cause this kind 
of logic in the client code.

Here is a real life sample I was able to find using Google Code search: 
http://tinyurl.com/mlc6zo
We are trying to load a cursor.  There are 3 different points were it 
can fail.  And we want to return a default cursor in case of any failure.

Another context were this kind of logic may appear are parsers.  Here is 
another real life sample: http://tinyurl.com/ljq5n9
I do not think that "cutting out" the "do { ... } while (false);" part 
into a separate function would add readability.

I do agree that it is possible to use this breakable construct 
incorrectly.  Actually most of the uses of "while (false)" that I have 
looked through (with exception of usages inside macros definitions) 
while looking for these examples were "incorrect" usages in a sense that 
using a separate function would improve readability.  My point is that 
not *all* usages of breakable construct are "archaic".  There are 
reasonable use cases.

Cretan languages support this "breakable" construct natively. 
OvermindDL1 wrote that D have something similar and it was designed 
quite recently.  I can add that Perl have direct support for this kind 
of control flow.  In Perl it looks like this:

{
   /* Code */

   last if /* block termination condition */

   /* More code */

   last if /* another block termination condition */

   /* The rest of the block code */
}
/* All "last" jumps here */

Almost exactly as in Gottlob Frege's hypothetical sample.

> 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.  [...]

It may be that I'm just missing your point, but it seems to me that you 
are telling that Boost should impose a certain coding style on its 
users.  Isn't it better to support different coding styles then to 
impose one on everyone around?

On a related topic I have just remembered that I have "discovered" 
another not very common but still recurring control flow construct.  In 
C++ it looks like this:

while (true)
{
     /* code */

     if (/* above code failed */)
         continue;

     /* code */

     if (/* failed */)
         continue;

     /* more code */

     break;
}

Perl is the only language I know of to have support of this construct 
almost natively.  It has a redo command that restarts current loop 
iteration and it treats an unnamed block as a loop that is executed once.

-- 
Ilya Bobir