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

Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-09-09 11:00:41

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

If it isn't common, does it deserve to be enshrined in Boost?  Maybe.

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

That's a horrible example.  The loop is used to jump to cleanup code that should be handled using RAII (a sentry would work nicely).

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

It would work nicely to create a separate function.  The subfunction can return early with a flag that indicates failure and the main function can assign to status and return 0.0.  Which is clearer would depend upon the reader, I suppose.

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

The point is that one *can* always rewrite the code a different way.  Perhaps the "breakable" approach makes certain code clearer, but it seems to apply to code that is already not exception safe and very C-like.

> 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:

That other languages do something doesn't mean it is a good idea, nor does its being in Perl mean it shouldn't be in C++. ;)

> > 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?

I believe his point was that Boost shouldn't encourage this style by enshrining the "Breakable Idiom."

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.