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 fart, 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. /David