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

Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?
From: Pierre Morcello (pmorcell-cppfrance_at_[hidden])
Date: 2009-09-09 17:34:30

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