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-09 19:24:04

Hi Pierre,

This position you have that some of us are arguing emotively and others
reasonably seems somewhat arbitrary. I claimed that the style
supported/encouraged by 'Breakable' is archaic. It is so because it is very
branchy and used for trapping error conditions and providing cleanup code.
We have ways to do that in C++ using RIAA and exceptions. We also have
Boost.ScopedExit.

In all cases where Breakable is used, refactoring to use a new function is
applicable - or, it can be argued, suggested. The argument against this
seems to be that adding more functions makes the code less readable. At this
point, we diverge and I claim that it is about style in that case. If this
is not 'factual' enough of an argument, I am at a loss.

I don't think Breakable adds anything of real value, and I personally would
never use it. As a lead programmer in the games industry, I also would not
let anyone in my team use it. Yes, it could be said to support old Win32
coding style, or old DirectX coding style, but these are terrible things to
want to support! Anyone that has ever read the DX SDK sample code realises
that it is madness to use the raw APIs directly. We wrap them in smart
objects and use those. We don't use them as is.

I firmly believe that this is really about style. I think that 'Breakable'
encourages bad style. There are "better" ways to do what it does, via
application of known idioms.

In any case, I am repeating myself so I'll let it be. Thanks for the making
proposal.

Kind Regards,
Christian.

On Thu, Sep 10, 2009 at 9:34 AM, Pierre Morcello <
pmorcell-cppfrance_at_[hidden]> wrote:

> I am surprised to find so many comments like "it smells bad", "it is
> archaic", "this is all about style" because these are based on feelings and
> not facts. Feelings are fine when you are looking for a solution to a
> scientific problem, but not for judging results. Feelings can be easily
> twisted (by culture, experience ...), cannot be discussed sanely and can
> lead to wrong results. (ex: there is a general formula to factorize polynom
> of degree 1,2,3,4... the feeling tells there is also one for 5, but with
> facts it was proven to be impossible).
>
> As a consequence, I will not try to discuss such points. On the contrary,
> the lasts answers written by Robert Stewart are in my opinion a good base to
> discuss, because they are clear and describe facts.
>
> //--------------------
> At Robert Stewart,
>
> First, I would like to present my deepest apologies, because I did not
> forsee a copy/paste problem within my webmail that inserted "double return"
> in my lines. This made the presentation of the code different from what I
> intended to present, and also from my whole mail. It was supposed to be
> exactly as you rewrote it.
> Now on the differents things that were mentionned, I happen to find that I
> share your point of view on many aspects.
> 1/ we agree on the fact that writing a 'subclass' inside the function is a
> nice solution to many problems.
> sourcePM : "If the sub-part is very specific and 'middle-big', a local
> struct with methods is much nicer."
> sourceRS : "Even if the original code in question is in a member function,
> the other functions need not be so"
>
> 2/ we agree that we need to use at least assertions of not documented
> functions
> sourcePM : "Without these comments, I suppose I will also end asserting
> everything in the code I already already tested back in the 'parent'
> function."
> sourceRS : "For preconditions and postconditions of implementation detail
> functions, I rely on assertions.  Documentation can easily become dated and
> the maintainers can easily follow the assertion logic."
> On this case, I had forgotten the problem of maintanability of the
> documentation that you explain.
>
> 3/ we agree that the code of a Breakable is vertically structured and very
> homogeneously presented.
> sourceRS : "That is a nice benefit."
>
> 4/ I also agree with you that even if something is present in another
> language, there is no reason to accept it as a good thing.
>
> The discussion you had with Ilya Bobir on the variety of code in the C++
> world me think to my own case.
> I worked for video games industry and develops today mainly 'serious
> games', focussing on 3D algorithms and using computer vision systems (I also
> teach at phd level these techniques, and lead research projects at my job on
> these subjects). I worked on weaponary systems and I also have a tiny
> experience with ERP coding. The coding rules are completely differents for
> these worlds.
> What you describe is the 'perfect C++' seen in ERP coding and weaponary
> systems for example. In that case, the project is specified clearly before
> the start, and the people working on it do not change every monthes.
> In video games industry, on the contrary you have to tests a lot of
> differents algorithms to satisfy a feeling, or a changing story, changing
> specifications ... there are also many 'tricks' everywhere.
> Just have a look at the "crysis game" code source : many functions are more
> than 50 lines long with many special cases (I am referring to the C++ part
> available in the 'crysis mod sdk'). You might think they got stupid coders,
> but the truth is that they oriented their code in a way that allowed easy
> and quick changes. This was the "less worst case" for them.
>
> Specifying a local struct for a local function is most of the time ok as
> long its number of parameters does not change 10 times a day (sometimes
> more)..
> Optimising an algorithms is also simplier when you got visual access to its
> function easily. So 4 embbeded brackets happens regularly. Asserting things
> that were already tested just before in another functino is also quite nasty
> : you need to code more and maintain more code than what you really use..
> For this reason also, game coders do not hesitate to write longer function.
>
> Of course everybody would like to use beautiful code. But during the
> developments, it just keeps changing a lot.
>
> Now, the more I think of it, the more I realize that while the 'Breakable'
> idiom is extremely handy for such developpments, it may not really be for
> others.
> This is making me understand your point of view even more.
>
> //-------------------
> To Kenneth :
> You wrote : "there is a book titled "Analysis Patterns" by Martin Fowler"
> Thanks, I will see if I can find more information on this book.
>
>
> //--------------------
> To everyone:
> >From the differents exchanges, right now I notice :
> -> the good usage of the Breakable is not to be used everywhere, but only
> when in front of a specific function with embedded if / else that are not
> too long.
> -> I continue to think this a good idiom, handy in many case I witnessed in
> my work.
> -> many advices against the Breakable, but some exchanges were based on
> feelings, not facts
> -> some people happy with the idea/idiom, but not interested in a library
> because it is a one liner.
> -> some people interested if there is something more with it.
> -> some people interested in unnamed local function through a macro that
> could also returns value.
>
> As a consequence, I have no plan to submit to boost anything in that state.
> I will have time to take a look deeper on the suggestions next week
> (because I am on holidays).
>
> Don't hesitate to judge my proposition with facts, or propose/suggest with
> feelings :-).
>
> Thanks a lot to everyone who answered,
>
> Pierre Morcello
>
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>