Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakablelibrary?
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-09-06 16:59:08
On Sep 6, 2009, at 4:30 PM, Pierre Morcello wrote:
> Thanks for sharing you point of view. At least you are not the only
> one who seems not interested !
>>>>> you might consider an overhaul of your code
> Please could you be a little more precise concerning the problems
> that you see ? ( because it sounds like 'this is bad but I don't
> tell you why').
>>> Is this concerning some compilers executing wrong statements ?
>>> Is it just concerning optimisations?
>>> Is it because you believe the code to be less readable / manageable?
>>>>>> My remark is not meant to be snide, just an advice from an old
> having wrestled, and eventually mastered, C++ for the last 20
> years :-)
> Don't worry! But I would like to point out something. There are
> people judging scientific documents by the name of the authors. I am
> not of this kind : even if you had only 1 year C++, I would listen
> to your remarks with interest, wondering if I forgot something, and
> if I can learn something from you.
Having been through a lot of hairy coding should definitely help in
seeing use cases for new constructs or macros. So, I would probably
listen more to a very experienced developer than a newbie. I would
actually listen a lot more to one who is smart and has done a lot of
different kinds of programming (and preferably with a multitude of
languages and platforms) but that is not revealed by one scalar
figure, such as 20, admittedly... There are many who code the exact
same thing over and over again for decades, just happy to bring home
some bacon to the table :-) So, in a sense you are right: a mere
scalar should not be the sole criterion for paying attention.
> Anyway, could you be more precise concerning the overhaul?
Why do you "break out" so often?
Having been the team lead for many, many developers - whereof a large
portion rather experienced - I see a lot of early returns, in various
blocks, and often in the form of loops or functions. I.e., using
'break' and 'return' frivolously. There are definitely cases where one
encounters a peculiar circumstance early in a block and want to "break
free" of the main logic. Luckily, languages like C++ do have
exceptions for those exceptional (...) cases.
But, as indicated, I have written a lot of threaded interpretation
code for abstract machines, so I know that Not Using Break is a rule
of thumb rather than the law. Emulating assembler (conditional
jumping, specifically) can definitely be the right approach - via
goto's and breaks - but should not be done prematurely.
To get a more concrete idea, you can send me, personally and out-of-
list, a code snippet with a lot of your breaks, and I will send back
an equivalent snippet without such breaks, indicating what performance
penalties one might have in cleansing the code from breaks.
The reason that I mentioned all this at all was that you talked about
making the code more readable by using your 'breakable construct',
where I here argue that if readability is a concern, one should be
wary of using breaks at all.