Boost logo

Boost :

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:
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:
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 */)

     /* code */

     if (/* failed */)

     /* more code */


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at