[Boost.Breakable] Any interest in a Boost Breakable library?
Hello, I propose a set of macros that allow to break anywhere. Example of use of the main macro : // do something... BOOST_BREAKABLE { if (test1) { break; } if (test2) { break; } std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } // here the program continues ... Is there any interest in such a library? Best regards, Pierre Morcello
Pierre Morcello wrote:
Hello,
I propose a set of macros that allow to break anywhere. Example of use of the main macro :
// do something... BOOST_BREAKABLE { if (test1) { break; } if (test2)
{
break;
}
std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } // here the program continues ...
Is there any interest in such a library?
What's the difference between this and a goto? Or a do ... while(false); loop? Both are probably shorter to write. Sebastian
Hi, there is no difference. Indeed, the macro as I use it right now is even less optimised than a GOTO or a do...while(false) : it's currently just a simple 'for' loop in a macro.. The aim is to make code more readable. A goto is a pain to manage when you use a lot this 'breakable' structure. The fact that it is easy to use and readable makes it easier to use a lot. In the end, I happen myself to use it lot more than I thougth I would at first. That is the main reason why I am proposing it here.
Both are probably shorter to write. Yes, although someone using such library may redefine the macro as he wishes : e.g. #define Breakable BOOST_BREAKABLE I am just conforming to BOOST coding style.
Pierre --- En date de : Dim 6.9.09, Sebastian Redl <sebastian.redl@getdesigned.at> a écrit : De: Sebastian Redl <sebastian.redl@getdesigned.at> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: boost@lists.boost.org Date: Dimanche 6 Septembre 2009, 9h10 Pierre Morcello wrote:
Hello,
I propose a set of macros that allow to break anywhere. Example of use of the main macro :
// do something... BOOST_BREAKABLE { if (test1) { break; } if (test2)
{
break;
}
std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } // here the program continues ...
Is there any interest in such a library? What's the difference between this and a goto? Or a do ... while(false); loop? Both are probably shorter to write.
Sebastian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Pierre Morcello wrote:
Indeed, the macro as I use it right now is even less optimised than a GOTO or a do...while(false) : it's currently just a simple 'for' loop in a macro..
I thought you were talking about a set of macros??? Apart from that, I like the idea. However, the idea is sufficient for me, I can just declare the macro myself, so no need for a library. Regards, Thomas
Hi,
I thought you were talking about a set of macros??? It is a set of macro because there is also a 'breakable if' and also 'breakable else'.
However, the idea is sufficient for me, I can just declare the macro myself Yes, I can understand that : I used to do the same than boost::non_copiable.. But I don't want to keep good ideas for myself.
There is clearly no technical difficulties here. It's more declaring : "there is an interesting way of programming some tedius tasks that use if/else/ do while contructs everywhere". Best regards, Pierre --- En date de : Dim 6.9.09, Thomas Klimpel <Thomas.Klimpel@synopsys.com> a écrit : De: Thomas Klimpel <Thomas.Klimpel@synopsys.com> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: "boost@lists.boost.org" <boost@lists.boost.org> Date: Dimanche 6 Septembre 2009, 11h04 Pierre Morcello wrote:
Indeed, the macro as I use it right now is even less optimised than a GOTO or a do...while(false) : it's currently just a simple 'for' loop in a macro..
I thought you were talking about a set of macros??? Apart from that, I like the idea. However, the idea is sufficient for me, I can just declare the macro myself, so no need for a library. Regards, Thomas _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Am Sunday 06 September 2009 20:46:42 schrieb Pierre Morcello:
Hi,
I thought you were talking about a set of macros???
It is a set of macro because there is also a 'breakable if' and also 'breakable else'.
However, the idea is sufficient for me, I can just declare the macro myself
Yes, I can understand that : I used to do the same than boost::non_copiable.. But I don't want to keep good ideas for myself.
There is clearly no technical difficulties here. It's more declaring : "there is an interesting way of programming some tedius tasks that use if/else/ do while contructs everywhere".
I've never seen such a case anywhere, let alone everywhere. if you need a construct that forms a scope, accomplishes a tasks and then exists the scope from anywhere in between, that's a function.
if you need a construct that forms a scope, accomplishes a tasks and then exists the scope from anywhere in between, that's a function.
Yes, I remember thinking like this at the beginning. But declaring a function each times sometimes makes the code less readable. It's like declaring a functor for iterating over all objects of a collection : you can do it but BOOST_FOREACH is just much more readable. What is more you need to give a name to your function. It's just more complicated than just writing the name of the macro. Creating a function when you only want to solve a break-scope problem is doing too much IMHO. It's using a specific aspect of the language that allows to break anywhere, not a tool that is meant to do it. Best regards, Pierre --- En date de : Dim 6.9.09, Stefan Strasser <strasser@uni-bremen.de> a écrit : De: Stefan Strasser <strasser@uni-bremen.de> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: boost@lists.boost.org Date: Dimanche 6 Septembre 2009, 13h43 Am Sunday 06 September 2009 20:46:42 schrieb Pierre Morcello:
Hi,
I thought you were talking about a set of macros???
It is a set of macro because there is also a 'breakable if' and also 'breakable else'.
However, the idea is sufficient for me, I can just declare the macro myself
Yes, I can understand that : I used to do the same than boost::non_copiable.. But I don't want to keep good ideas for myself.
There is clearly no technical difficulties here. It's more declaring : "there is an interesting way of programming some tedius tasks that use if/else/ do while contructs everywhere".
I've never seen such a case anywhere, let alone everywhere. if you need a construct that forms a scope, accomplishes a tasks and then exists the scope from anywhere in between, that's a function. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sep 6, 2009, at 4:05 PM, Pierre Morcello wrote:
if you need a construct that forms a scope, accomplishes a tasks and then exists the scope from anywhere in between, that's a function.
Yes, I remember thinking like this at the beginning. But declaring a function each times sometimes makes the code less readable. It's like declaring a functor for iterating over all objects of a collection : you can do it but BOOST_FOREACH is just much more readable. What is more you need to give a name to your function. It's just more complicated than just writing the name of the macro.
Creating a function when you only want to solve a break-scope problem
What is a "break-scope problem" to you? I think you might use the wrong "analysis pattern" here...
is doing too much IMHO. It's using a specific aspect of the language that allows to break anywhere, not a tool that is meant to do it
/David
What is a "break-scope problem" to you? I think you might use the wrong "analysis pattern" here...
I was reusing the same kind of words than the previous comment of Stefan Strasser, to answer clearly to his remarks. Sorry if it made things less clear: He wrote "if you need a construct that forms a scope, accomplishes a tasks and then exists the scope from anywhere in between, that's a function.". He was presenting things like a problem and its solution. I have never heard of 'analysis pattern', only 'design patterns' and 'idioms'. I will look at this. Anyway just let compare 2 sample codes: Of course people can already write : if(!filestream.bad()) { if(!filestream.good()) { if(xmlLoadFrom(filestream)) { // and so on, to test if the xml is valid, etc... }else{ log("the file is no xml document."); } }else{ log("error inside the file (eof)"); } }else{ log("error at opening file"); } and : Breakable { if(!filestream.bad()) { log("error at opening file"); break; } if(!filestream.good()) { log("error inside the file (eof)"); break; } if(!xmlLoadFrom(filestream)) { log("the file is no xml document."); break; } // and so on, to test if the xml is valid, etc... } Have a deep breath, compare, and then tell me which is more readable. Which is the easier to maintain? If another test is to be added, which version will be the simpliest to modify? For these 3 reasons, I prefer the second one. If you think this usage might lead to problems, could you explain which ones ? Best regards, Pierre PS: if you know a good source about "analysis pattern", don't hesitate to tell me. Right now, I will check the wikipedia page. --- En date de : Dim 6.9.09, David Bergman <David.Bergman@bergmangupta.com> a écrit : De: David Bergman <David.Bergman@bergmangupta.com> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: boost@lists.boost.org Date: Dimanche 6 Septembre 2009, 13h08 On Sep 6, 2009, at 4:05 PM, Pierre Morcello wrote:
if you need a construct that forms a scope, accomplishes a tasks and then exists the scope from anywhere in between, that's a function.
Yes, I remember thinking like this at the beginning. But declaring a function each times sometimes makes the code less readable. It's like declaring a functor for iterating over all objects of a collection : you can do it but BOOST_FOREACH is just much more readable. What is more you need to give a name to your function. It's just more complicated than just writing the name of the macro.
Creating a function when you only want to solve a break-scope problem
What is a "break-scope problem" to you? I think you might use the wrong "analysis pattern" here...
is doing too much IMHO. It's using a specific aspect of the language that allows to break anywhere, not a tool that is meant to do it
/David _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sep 6, 2009, at 5:09 PM, Pierre Morcello wrote:
What is a "break-scope problem" to you? I think you might use the wrong "analysis pattern" here...
I was reusing the same kind of words than the previous comment of Stefan Strasser, to answer clearly to his remarks. Sorry if it made things less clear: He wrote "if you need a construct that forms a scope, accomplishes a tasks and then exists the scope from anywhere in between, that's a function.". He was presenting things like a problem and its solution.
I have never heard of 'analysis pattern', only 'design patterns' and 'idioms'. I will look at this.
Anyway just let compare 2 sample codes:
Of course people can already write : if(!filestream.bad()) { if(!filestream.good()) { if(xmlLoadFrom(filestream)) { // and so on, to test if the xml is valid, etc... }else{ log("the file is no xml document."); } }else{ log("error inside the file (eof)"); } }else{ log("error at opening file"); }
and :
Breakable { if(!filestream.bad()) { log("error at opening file"); break; }
if(!filestream.good()) { log("error inside the file (eof)"); break; }
if(!xmlLoadFrom(filestream)) { log("the file is no xml document."); break; }
// and so on, to test if the xml is valid, etc... }
Have a deep breath, compare, and then tell me which is more readable. Which is the easier to maintain? If another test is to be added, which version will be the simpliest to modify?
For these 3 reasons, I prefer the second one.
If you think this usage might lead to problems, could you explain which ones ?
This is the typical use, that of exceptional cases. Luckily, what is exceptional at one level can be totally tolerable at a higher (and invoking and/or embedding...) level, thus we can use a try-catch construct and throw an exception. I am not a friend of emulating local exception handling by breaks. So, in this case (and even meta case) I would use try { if (filestream.bad()) throw boost::exception("error at opening file"); if (!filestream.good()) throw boost::exception("error inside the file (eof)"); // Main logic xmlLoadFrom(filestream); // assuming that 'xmlLoadFrom' uses exceptions properly as well... } catch (const boost::exception& ex) { log(ex.what()); }
Best regards,
Pierre
PS: if you know a good source about "analysis pattern", don't hesitate to tell me. Right now, I will check the wikipedia page.
I just coined that term - at least AFAIK. What I meant by it? Well, similar to design pattern but applied in the analysis of problems, as a Minsky frame, perhaps. /David
This is the typical use, that of exceptional cases. Luckily, what is exceptional at one level can be totally tolerable at a higher (and invoking and/or embedding...) level, thus we can use a try-catch construct and throw an exception.
Ok, you wrote just before that :
I will send back an equivalent snippet without such breaks, indicating what performance penalties one might have in cleansing the code from breaks.
So I suppose we are ok to forget the performances impact, if I look at your 'exception-based' system :-). As I said performance of the proposed 'Breakable struct' are not perfect, but I believe it to be much better than your exception-based solution. Anyway, considering exception, it is a good way to do it, but : 1/ exception are not available on every platform 2/ If I want to throw an exception to an outside function (ex:bad_alloc), instead of breaking inside the 'breakable structure' this can make things less manageable (obliged carefully select exception types, or even rethrow if needed etc...). 3/ I find the 'breakable structure' still much more readable than the exception one. When you use Exception, you are forced to 'catch' correctly. This can go out of scope easily if you make a mistake. And if you make a mistake in the kind of exception you throw, the compiler won't tell you. When you got only 1 macro to write, sincerily, how could you make a mistake? This is about writing code that won't allow to do more error. Code cleanness and readability. A last element about exception and how not to abuse them : " There are two basic questions you should ask yourself when deciding whether to throw an exception in response to some event. The first is (1) "should this event occur in the normal use of my library component?" The second question is (2) "if this event were to occur, is it likely that the user will want to place the code for dealing with the event near the invocations of my library component?" If your answers to the above two questions are "no" then you should probably throw an exception in response to the event. On the other hand, if you answer "yes" to either of these questions then you should probably not throw an exception. "source :http://dclib.sourceforge.net/howto_contribute.html#8 With this kind of thinking, it also seems clear that exception are overkill in the case of most uses of a 'breakable structure'. Best regards, Pierre --- En date de : Dim 6.9.09, David Bergman <David.Bergman@bergmangupta.com> a écrit : De: David Bergman <David.Bergman@bergmangupta.com> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: boost@lists.boost.org Date: Dimanche 6 Septembre 2009, 14h29 On Sep 6, 2009, at 5:09 PM, Pierre Morcello wrote:
What is a "break-scope problem" to you? I think you might use the wrong "analysis pattern" here...
I was reusing the same kind of words than the previous comment of Stefan Strasser, to answer clearly to his remarks. Sorry if it made things less clear: He wrote "if you need a construct that forms a scope, accomplishes a tasks and then exists the scope from anywhere in between, that's a function.". He was presenting things like a problem and its solution.
I have never heard of 'analysis pattern', only 'design patterns' and 'idioms'. I will look at this.
Anyway just let compare 2 sample codes:
Of course people can already write : if(!filestream.bad()) { if(!filestream.good()) { if(xmlLoadFrom(filestream)) { // and so on, to test if the xml is valid, etc... }else{ log("the file is no xml document."); } }else{ log("error inside the file (eof)"); } }else{ log("error at opening file"); }
and :
Breakable { if(!filestream.bad()) { log("error at opening file"); break; }
if(!filestream.good()) { log("error inside the file (eof)"); break; }
if(!xmlLoadFrom(filestream)) { log("the file is no xml document."); break; }
// and so on, to test if the xml is valid, etc... }
Have a deep breath, compare, and then tell me which is more readable. Which is the easier to maintain? If another test is to be added, which version will be the simpliest to modify?
For these 3 reasons, I prefer the second one.
If you think this usage might lead to problems, could you explain which ones ?
This is the typical use, that of exceptional cases. Luckily, what is exceptional at one level can be totally tolerable at a higher (and invoking and/or embedding...) level, thus we can use a try-catch construct and throw an exception. I am not a friend of emulating local exception handling by breaks. So, in this case (and even meta case) I would use try { if (filestream.bad()) throw boost::exception("error at opening file"); if (!filestream.good()) throw boost::exception("error inside the file (eof)"); // Main logic xmlLoadFrom(filestream); // assuming that 'xmlLoadFrom' uses exceptions properly as well... } catch (const boost::exception& ex) { log(ex.what()); }
Best regards,
Pierre
PS: if you know a good source about "analysis pattern", don't hesitate to tell me. Right now, I will check the wikipedia page.
I just coined that term - at least AFAIK. What I meant by it? Well, similar to design pattern but applied in the analysis of problems, as a Minsky frame, perhaps. /David _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
In fact, there is a book titled "Analysis Patterns" by Martin Fowler. I do not know if it is a "good" source, it just happens to be sitting in my desk now, in a sort of book inbox of mine. Kenneth David Bergman-3 wrote:
On Sep 6, 2009, at 5:09 PM, Pierre Morcello wrote:
Best regards,
Pierre
PS: if you know a good source about "analysis pattern", don't hesitate to tell me. Right now, I will check the wikipedia page.
I just coined that term - at least AFAIK. What I meant by it? Well, similar to design pattern but applied in the analysis of problems, as a Minsky frame, perhaps.
/David
-- View this message in context: http://www.nabble.com/-Boost.Breakable--Any-interest-in-a-Boost-Breakable-li... Sent from the Boost - Dev mailing list archive at Nabble.com.
Pierre Morcello wrote:
Breakable { if(!filestream.bad()) { log("error at opening file"); break; }
if(!filestream.good()) { log("error inside the file (eof)"); break; }
if(!xmlLoadFrom(filestream)) { log("the file is no xml document."); break; }
// and so on, to test if the xml is valid, etc... }
And why not just add the else? if(!filestream.bad()) { log("error at opening file"); } else if(!filestream.good()) { log("error inside the file (eof)"); } else if(!xmlLoadFrom(filestream)) { log("the file is no xml document."); } -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
Thanks Michael, I did not think sooner to the 'else if'. But there is one problem with the 'else if' : you can not do calculations between the tests. When I work often my code looks like : // retrieve meshes from prototype Breakable { // find loaded meshes std::set<Mesh*> lLoadedMeshes; { // some calculations that fill lLoadedMeshes } if(lLoadedMeshes.empty()) { break; } // find loadable scenes that uses the already loaded meshes std::set<Scene*> lLoadableScenes; { // some calculations that fill lLoadableScenes // it uses the result of lLoadedMeshes } if(lLoadedScenes.empty()) { break; } // and so on.. } In that case, the 'breakable' is justified in my opinion, whereas in the example you gave, the 'else if ' seems even simplier. --- En date de : Dim 6.9.09, Michael Caisse <boost@objectmodelingdesigns.com> a écrit : De: Michael Caisse <boost@objectmodelingdesigns.com> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: boost@lists.boost.org Date: Dimanche 6 Septembre 2009, 22h43 Pierre Morcello wrote:
Breakable { if(!filestream.bad()) { log("error at opening file"); break; }
if(!filestream.good()) { log("error inside the file (eof)"); break; }
if(!xmlLoadFrom(filestream)) { log("the file is no xml document."); break; } // and so on, to test if the xml is valid, etc... }
And why not just add the else? if(!filestream.bad()) { log("error at opening file"); } else if(!filestream.good()) { log("error inside the file (eof)"); } else if(!xmlLoadFrom(filestream)) { log("the file is no xml document."); } -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'm very sorry if I missed it in an earlier comment, but what's wrong with simply returning from the function? This all just smells bad to me. On Sun, Sep 6, 2009 at 11:14 PM, Pierre Morcello < pmorcell-cppfrance@yahoo.fr> wrote:
Thanks Michael, I did not think sooner to the 'else if'. But there is one problem with the 'else if' : you can not do calculations between the tests.
When I work often my code looks like :
// retrieve meshes from prototype Breakable { // find loaded meshes std::set<Mesh*> lLoadedMeshes; { // some calculations that fill lLoadedMeshes }
if(lLoadedMeshes.empty()) { break; }
// find loadable scenes that uses the already loaded meshes std::set<Scene*> lLoadableScenes; { // some calculations that fill lLoadableScenes // it uses the result of lLoadedMeshes }
if(lLoadedScenes.empty())
{
break;
}
// and so on.. }
In that case, the 'breakable' is justified in my opinion, whereas in the example you gave, the 'else if ' seems even simplier.
--- En date de : Dim 6.9.09, Michael Caisse < boost@objectmodelingdesigns.com> a écrit :
De: Michael Caisse <boost@objectmodelingdesigns.com> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: boost@lists.boost.org Date: Dimanche 6 Septembre 2009, 22h43
Pierre Morcello wrote:
Breakable { if(!filestream.bad()) { log("error at opening file"); break; }
if(!filestream.good()) { log("error inside the file (eof)"); break; }
if(!xmlLoadFrom(filestream)) { log("the file is no xml document."); break; } // and so on, to test if the xml is valid, etc... }
And why not just add the else?
if(!filestream.bad()) { log("error at opening file"); } else if(!filestream.good()) { log("error inside the file (eof)"); } else if(!xmlLoadFrom(filestream)) { log("the file is no xml document."); }
-- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- GMan, Nick Gorski
Thanks for your time, I answer to everyone here.
// -----------------
GMan wrote:
"I'm very sorry if I missed it in an earlier comment, but what's wrong with
simply returning from the function? This all just smells bad to me."
Thanks for your point of view. What's wrong with simply returning from the function?
Well let's say I want to use several structures several times :
example :
"
// part1 getting all infos from the headers
HeaderInformations lInfos;
// fill lInfos with some infos generated by the prog.
{
// do things...
}
Breakable
{
//here I do some tests and then I grow lInfos with other things found in the file if there is no problem
// thanks to the 'break', my code has a vertical disposition instead of an embedded set of if/else.
}
BOOST_FOREACH(HeaderInformation & lInfo, lInfos)
{
// initialise settings
}
"
So in this example, if I put a 'return' instead of the 'breakable struct' I can't initialise things that were already in lInfos.
Then you may want to define a function to handle the the 'breakable struct' with returns. This means, either modifying your .h by adding new function that have a very specific purpose (and also separate the code from where it is used), either declaring an embedded function through a local struct. Neither of those is very satisfying in my opinion. In both case you end up with something more complicated to maintain that what you want (not even speaking of the parameters to transmit).
>>>"This all just smells bad to me"
Well, the 'feeling only' is something very difficult to appreciate. If you got clearer objection, concerning : a better solution, optimisation, readability, maintainability, this would be easier for me to understand your point. I never suspected as I began to use this macro that I would use it so often, with such ease : as you do, I was not convinced myself when I began. It was just a test within hundreds of other C++ curiosity. It happens that I find this one much more useful than I suspected it would be.
// -----------------
OvermindDL1 wrote :
"
Actually the D language has such named blocks and jumps to parent
loops from child ones and so forth, might look at it as an example...
"
Thanks I did not know that, I will give it an eye.
// -----------------
Gottlob Frege wrote :
>>> "I think I would be fine with it, if it was built into the language."
Yes, I share the same feeling as you concerning the different solutions and the fact that an hypothetical language support would be much more pleasant..
>>>>>"If I DID start using it regularly, I'd definitely want it to be in boost, even if it was tiny
- because then it would become a known and understood idiom. "
This is exactly the main reason why I am posting here. The idiom is more important than the library itself. Here I want to note something that I find very important :
>>>>"I think I recall proposals for 'named' breaks, and multilevel breaks as well?"
I did not know. I will do a search, but I am not convinced I would use something more complicated than the "keep it stupid simple" version of the current 'Breakable' macro.
I appreciated your presentation. I did not dare to do one myself in my first post (I do not want to scare people!).
>>>>ie why not allow a break out of 'unnamed' blocks?
Well, I think unnamed blocks have already other purpose : make the code clearer, limit the life time of variables. "break" of 'unnamed' blocks would be more tricky than simple. Not to mention than, suppose someone comes and do not see the "break", he changes the brackets and make a bug appear, which could be quite difficult to spot. I thought a lot about all this before proposing here, and my conclusion was that the 'Breakable' is right now the nicest solution (or the 'less bad' if you prefer ;-)).
//-------------
Martin Törnwall wrote:
"
I think this is an excellent idea. Though the do...while(false) trick is
a rather handy one, I've always felt that it its purpose might not be
clear enough, especially to someone who has never encountered it before.
However, I agree with Thomas: this is a one-line macro, and it should be
portable between all standards compliant C++ compilers. There is simply
no need to create a library just for this feature. Perhaps you could
expand upon it a bit?
"
Thanks for the suggestion. I have 2 other macro (a "breakable if" and "breakable else"). So this is already 200% bigger. Of course, I worked on many other horrible macro systems and post-processor magic in my hdd, (for example support for function declarations like : void put(int value)into(std::vector()) const;), but from my own point of view I prefer to keep only the best for the outside world. In my case it is a one-liner. To be able to keep things simple when they don't need to be complicated is very important (the KISS principle).
On the other hand, if I need another "decorative functionality" to make the whole thing look more complicated so that it may be accepted... O_O... well why not? If you got ideas about Breakable, tell me, I will anyway have also a look to
the suggestions that were made (D language, and maybe previous
proposals).
I think myself that a library may be too much. But if you look at boost::non_copyable for example, it is neither difficult to do, neither long. - There are some one-liner that are themselves much more complicated than
boost::non_copyable (for example the quick inverse-square-root of
quake3) -. For that reason, I think that somewhere near the "boost/utility" header could be a good place for the 'Breakable'.
>From the boost library submission process page :
"Aim first for clarity and correctness; optimization should
be only a secondary concern in most Boost libraries."
I think the 'Breakable' proposition already fits perfectly.
Best regards,
Pierre Morcello
--- En date de : Lun 7.9.09, GMan <gmannickg@gmail.com> a écrit :
De: GMan <gmannickg@gmail.com>
Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?
À: boost@lists.boost.org
Date: Lundi 7 Septembre 2009, 0h07
I'm very sorry if I missed it in an earlier comment, but what's wrong with
simply returning from the function? This all just smells bad to me.
On Sun, Sep 6, 2009 at 11:14 PM, Pierre Morcello <
pmorcell-cppfrance@yahoo.fr> wrote:
> Thanks Michael, I did not think sooner to the 'else if'. But there is one
> problem with the 'else if' : you can not do calculations between the tests.
>
> When I work often my code looks like :
>
> // retrieve meshes from prototype
> Breakable
> {
> // find loaded meshes
> std::set<Mesh*> lLoadedMeshes;
> {
> // some calculations that fill lLoadedMeshes
> }
>
> if(lLoadedMeshes.empty())
> {
> break;
> }
>
> // find loadable scenes that uses the already loaded meshes
> std::set<Scene*> lLoadableScenes;
> {
> // some calculations that fill lLoadableScenes
> // it uses the result of lLoadedMeshes
> }
>
>
> if(lLoadedScenes.empty())
>
> {
>
> break;
>
> }
>
> // and so on..
> }
>
> In that case, the 'breakable' is justified in my opinion, whereas in the
> example you gave, the 'else if ' seems even simplier.
>
>
> --- En date de : Dim 6.9.09, Michael Caisse <
> boost@objectmodelingdesigns.com> a écrit :
>
> De: Michael Caisse <boost@objectmodelingdesigns.com>
> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable
> library?
> À: boost@lists.boost.org
> Date: Dimanche 6 Septembre 2009, 22h43
>
> Pierre Morcello wrote:
> > Breakable
> > {
> > if(!filestream.bad())
> > {
> > log("error at opening file");
> > break;
> > }
> >
> > if(!filestream.good())
> > {
> > log("error inside the file (eof)");
> > break;
> > }
> >
> > if(!xmlLoadFrom(filestream))
> > {
> > log("the file is no xml document.");
> > break; }
> > // and so on, to test if the xml is valid, etc...
> > }
> >
> >
>
>
> And why not just add the else?
>
> if(!filestream.bad())
> {
> log("error at opening file");
> }
> else if(!filestream.good())
> {
> log("error inside the file (eof)");
> }
> else if(!xmlLoadFrom(filestream))
> {
> log("the file is no xml document.");
> }
>
>
> --
> ----------------------------------
> Michael Caisse
> Object Modeling Designs
> www.objectmodelingdesigns.com
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
--
GMan, Nick Gorski
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Sep 7, 2009 at 2:14 AM, Pierre Morcello<pmorcell-cppfrance@yahoo.fr> wrote:
Thanks Michael, I did not think sooner to the 'else if'. But there is one problem with the 'else if' : you can not do calculations between the tests.
When I work often my code looks like : ...
Another 'lifer' here (20+ years!) :-) I think, by now, we all know and have seen the type of code you are talking about. I saw it a lot with Windows GUI programming - get the HWND, check, Get the DC, check, do some stuff, make a HPEN, check,... I have yet to see a perfect solution. Some of the solutions I've seen: 1) try to do all the checks at the top: void func(P1 p1, P2 p2, ...) { if (!IsOK(p1)) return; if (!IsOK(p2)) return; etc now do stuff... } I think this is pretty good if all the checks are just checking inputs. but it gets hairy in those cases, as mentioned, when there is other code in between. An alternative to this is to 2) do checks, then pass it down to unchecked functions: void func(P1 p1, P2 p2, ...) { if (!IsOK(p1)) return; if (!IsOK(p2)) return; return unchecked_func(p1, p2, ...); } This actually CAN (somewhat) work with code in between - after every single check you call another smaller function. But you end up with a cascade of functions (hard to follow) and you quickly run out of good names or reuse the same name if the param types have changed. But it can also be helpful if the inner functions can be reused in cases where you, say, already had a DC or HPEN or something. ie void func(P1 p1, P2 p2, ...) { Q q = getQ(p1); if (!IsOK(q)) return; return foo(q, p2,...); // then foo(Q,...) then assumes Q, handles p2, maybe calls down another layer. } 3) use gotos Maybe gotos are evil, but I've seen 'goto cleanup' or 'goto endoffunction' and it doesn't really bother me that much. It is sort of a poor man's 'finally' construct. As long as you are not going to multiple labels, or going back to the top (ie only 'goto' to labels closer to the end of the function) I can live with it. 4) mulitple returns strewn about I think there are a few reasons to avoid multiple returns, but a few of them need revisiting. In particular, one reason was that multiple returns tended to cause resources to go un-destructed. At least in the C days. But now, if we are coding to be exception safe, then basically we are dealing with multiple return points whether we want to or not. ie if an exception happens in the middle of the function, then that's where we are 'returning' from. Or at least realize that if everything is RAII and exception safe, then the code is also 'return safe'. Multiple return points might still be harder to read and reason with (although not much different than multiple breaks), but at least it should now be 'safe'. P.S. multiple returns were once hard to debug, (you had to put breakpoints at every return if you didn't want to miss your exit) but now you can typically put a breakpoint at the closing '}' of the function itself, and catch them all (although you still might not know which one it was). 5) exceptions I've tried throwing exceptions, but found a few things a) some of the errors were not 'exceptional' b) it felt odd (to me) to catch exceptions thrown within the same function (as opposed to catching exceptions thrown from lower levels) c) it didn't look like less code than other solutions Of course, there are cases where the errors SHOULD be thrown up to a higher level, and that does make the code cleaner (particularly if there is NO catching in the current function) so it would make sense to use it in those situations. 6) Your 'Breakable' idiom Well, I haven't tried it. I really dislike macros. Probably that would be enough to stop me. Not sure I like for (bool executed=false;!executed;executed=true) any better. I'd have to comment that, and then why not use a macro, which would be a comment at the same time. 7?) Interestingly, I think I would be fine with it, if it was built into the language. ie why not allow a break out of 'unnamed' blocks? (besides breaking some existing code with these blocks within loops, of course :-) { if (bad(x)) break; y = ....; if (!y) break; } I think I recall proposals for 'named' breaks, and multilevel breaks as well? Anyhow, I think that is a long way for me to just say "I feel your pain", and I wish there was a nicer solution (that was part of the language). I might even try your style. If I DID start using it regularly, I'd definitely want it to be in boost, even if it was tiny - because then it would become a known and understood idiom. But I'd prefer better language support instead. Tony
On Mon, Sep 7, 2009 at 1:40 AM, Gottlob Frege<gottlobfrege@gmail.com> wrote:
On Mon, Sep 7, 2009 at 2:14 AM, Pierre Morcello<pmorcell-cppfrance@yahoo.fr> wrote:
Thanks Michael, I did not think sooner to the 'else if'. But there is one problem with the 'else if' : you can not do calculations between the tests.
When I work often my code looks like : ...
Another 'lifer' here (20+ years!) :-)
I think, by now, we all know and have seen the type of code you are talking about. I saw it a lot with Windows GUI programming - get the HWND, check, Get the DC, check, do some stuff, make a HPEN, check,...
I have yet to see a perfect solution. Some of the solutions I've seen:
1) try to do all the checks at the top:
void func(P1 p1, P2 p2, ...) { if (!IsOK(p1)) return; if (!IsOK(p2)) return; etc
now do stuff... }
I think this is pretty good if all the checks are just checking inputs. but it gets hairy in those cases, as mentioned, when there is other code in between. An alternative to this is to
2) do checks, then pass it down to unchecked functions: void func(P1 p1, P2 p2, ...) { if (!IsOK(p1)) return; if (!IsOK(p2)) return;
return unchecked_func(p1, p2, ...); }
This actually CAN (somewhat) work with code in between - after every single check you call another smaller function. But you end up with a cascade of functions (hard to follow) and you quickly run out of good names or reuse the same name if the param types have changed. But it can also be helpful if the inner functions can be reused in cases where you, say, already had a DC or HPEN or something. ie
void func(P1 p1, P2 p2, ...) { Q q = getQ(p1); if (!IsOK(q)) return; return foo(q, p2,...); // then foo(Q,...) then assumes Q, handles p2, maybe calls down another layer. }
3) use gotos Maybe gotos are evil, but I've seen 'goto cleanup' or 'goto endoffunction' and it doesn't really bother me that much. It is sort of a poor man's 'finally' construct. As long as you are not going to multiple labels, or going back to the top (ie only 'goto' to labels closer to the end of the function) I can live with it.
4) mulitple returns strewn about I think there are a few reasons to avoid multiple returns, but a few of them need revisiting. In particular, one reason was that multiple returns tended to cause resources to go un-destructed. At least in the C days. But now, if we are coding to be exception safe, then basically we are dealing with multiple return points whether we want to or not. ie if an exception happens in the middle of the function, then that's where we are 'returning' from. Or at least realize that if everything is RAII and exception safe, then the code is also 'return safe'. Multiple return points might still be harder to read and reason with (although not much different than multiple breaks), but at least it should now be 'safe'. P.S. multiple returns were once hard to debug, (you had to put breakpoints at every return if you didn't want to miss your exit) but now you can typically put a breakpoint at the closing '}' of the function itself, and catch them all (although you still might not know which one it was).
5) exceptions I've tried throwing exceptions, but found a few things a) some of the errors were not 'exceptional' b) it felt odd (to me) to catch exceptions thrown within the same function (as opposed to catching exceptions thrown from lower levels) c) it didn't look like less code than other solutions Of course, there are cases where the errors SHOULD be thrown up to a higher level, and that does make the code cleaner (particularly if there is NO catching in the current function) so it would make sense to use it in those situations.
6) Your 'Breakable' idiom Well, I haven't tried it. I really dislike macros. Probably that would be enough to stop me. Not sure I like
for (bool executed=false;!executed;executed=true)
any better. I'd have to comment that, and then why not use a macro, which would be a comment at the same time.
7?) Interestingly, I think I would be fine with it, if it was built into the language. ie why not allow a break out of 'unnamed' blocks? (besides breaking some existing code with these blocks within loops, of course :-)
{ if (bad(x)) break; y = ....; if (!y) break; }
I think I recall proposals for 'named' breaks, and multilevel breaks as well?
Anyhow, I think that is a long way for me to just say "I feel your pain", and I wish there was a nicer solution (that was part of the language). I might even try your style. If I DID start using it regularly, I'd definitely want it to be in boost, even if it was tiny - because then it would become a known and understood idiom. But I'd prefer better language support instead.
Actually the D language has such named blocks and jumps to parent loops from child ones and so forth, might look at it as an example...
Pierre Morcello wrote:
Thanks Michael, I did not think sooner to the 'else if'. But
I like the "else if" version better, too.
there is one problem with the 'else if' : you can not do calculations between the tests.
When I work often my code looks like :
// retrieve meshes from prototype Breakable { // find loaded meshes std::set<Mesh*> lLoadedMeshes; { // some calculations that fill lLoadedMeshes }
if(lLoadedMeshes.empty()) { break; }
// find loadable scenes that uses the already loaded meshes std::set<Scene*> lLoadableScenes; { // some calculations that fill lLoadableScenes // it uses the result of lLoadedMeshes }
if(lLoadedScenes.empty())
{
break;
}
// and so on.. }
The whole point of your scheme is to skip subsequent code if you encounter some sort of error. Therefore, this will do nicely: { std::set<Mesh*> lLoadedMeshes; if (!find_loaded_meshes(lLoadedMeshes)) { // complain and return or throw } std::set<Scene*> lLoadableScenes; if (!find_loadable_scenes(lLoadableScenes, lLoadedMeshes)) { // complain and return or throw } // and so on.. } bool find_loaded_meshes(std::set<Mesh*> & _meshes) { // some calculations that fill _meshes if (_meshes.empty()) { return false; } // do more return true; } bool find_loadable_scenes(std::set<Scene*> & _scenes, std::set<Mesh*> const & _meshes) { { // some calculations that fill lLoadableScenes // it uses the result of _meshes } if (_scenes.empty()) { return false; } // do more return true; } You said before that splitting things into multiple functions reduced readability. My version is more readable for several reasons. Each function has a single purpose rather than one function doing many things. Notice that I removed some comments in your version because the function names obviated them (self- documenting code). Finally, the high level logic, in the initial block, is clearer, while the low level logic is segregated into separate functions. If you'd prefer to avoid early returns, "else" is handy: { std::set<Mesh*> lLoadedMeshes; if (!find_loaded_meshes(lLoadedMeshes)) { // complain and return or throw } else { std::set<Scene*> lLoadableScenes; if (!find_loadable_scenes(lLoadableScenes, lLoadedMeshes)) { // complain and return or throw } // and so on.. } } _____ Rob Stewart robert.stewart@sig.com 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.
Stewart, Robert wrote :
"You said before that splitting things into multiple functions reduced readability. My version is more readable for several reasons. Each function has a single purpose rather than one function doing many things. Notice that I removed some comments in your version because the function names obviated them (self- documenting code). Finally, the high level logic, in the initial block, is clearer, while the low level logic is segregated into separate functions."
Please don't misunderstand me : I don't think that splitting things into multiple functions reduce readability. I think that in some case it reduces readability and also maintanability of the code. You can increase readibility in some case. As an example, with BOOST_FOREACH macro, you don't need to split the code into some functors to make it run (this is explained more simply on the page of the library). Your function proposition has also some side effects, that you think are nice, and that I think are not nice. This is due to a misunderstanding between us on the kind of work we suppose the 'subfunctions' will do. I explain myself in the following paragraphes. 0/ just a side note. In the case of the "find Loaded Meshes", in fact I was thinking to a very special case of a memory manager of a 3D game that is -during loading threaded resources- updating some data before final cleaning of its state. It just means that there is already a findLoadedMeshes() function, for the user of the class, and it uses the cleaned set of information, not the 'dirty' one being loaded as supposed in my example. So the name of the function, must be chosen carefully to suppress any doubt from the reader. 1/ One side effect in your approach is that it forces the user to declare the function in the .h. If there is no use to reuse the code (because it is extremely specific to the function), then you are polluting the .h with things that are not information specific to the class, but only to one function. 2/ If I have to declare the function in the .h, I may end writing : "void _myfuntion_findLoadedMeshes()" in private, with a doxygen description on top of it. Why such a description if the code is 'self explanatory'? The reason is : each of my function got a set of preconditions to tests, sometimes post conditions, and I would not ask someone to maintain a system without these informations. Without these comments, I suppose I will also end asserting everything in the code I already already tested back in the 'parent' function. As a matter of fact I have already seen guys who were testing a boolean member as a precondition to see if the function was called just after the 'supposed previous call'. So there is a need to restrain the use of the 'sub-function' to the 'parent function' only. My conclusion on this 'keep the h clean' part is : if the 'sub-part' is big or to be reused, 'function split' (as you proposed) or even aggregation is the way to go. If the sub-part is very specific and 'middle-big', a local struct with methods is much nicer. In the last case, if the 'sub-part' is little and very specific, you will appreciate the 'Breakable' idiom. 3/ possible errors creation during subfunction writing. When you write the 'Breakable', you are only writing 1 line. It is very hard to write something wrong at that level. When you declare the subfunctions, you have to declare the parameters, also gives them meaningfull names. Most of the time, let say I have between 2 or 3 parameters to give to the subfunction. 1 time out of 3 I have a std container to transmit. Someone with less experience than me (or myself when I am tired) could write "bool find_loaded_meshes(std::set<Mesh*> _meshes)" and forgetting the & in the definition. Then copy/pasting the result to write quickier its declaration, it stays the same. Then, if the function is just checking things inside the container, you got a real performance hit for free. Otherwise you will find this error soon when it bugs. So conclusion on that point is : this will take you more time and length to code, and is more prone to some errors (even if they are rare / not tragic). 4/ People write a function when they need one, not in order to manage a syntax problem. You supposed I don't know when I should write a function. Well, as a matter of fact, the problem is the other way round : I am studying the case when the user knows he does not need any function at that point, and he only needs syntactic sugar. I will answer more specifically to the "handy embedded if{}else{}" solution in another mail, to make things a little clearer on that point (because there is much to say). Thanks for your time and propositions, Best regards, Pierre Morcello --- En date de : Mar 8.9.09, Stewart, Robert <Robert.Stewart@sig.com> a écrit : De: Stewart, Robert <Robert.Stewart@sig.com> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: "boost@lists.boost.org" <boost@lists.boost.org> Date: Mardi 8 Septembre 2009, 7h14 Pierre Morcello wrote: > > Thanks Michael, I did not think sooner to the 'else if'. But I like the "else if" version better, too. > there is one problem with the 'else if' : you can not do > calculations between the tests. > > When I work often my code looks like : > > // retrieve meshes from prototype > Breakable > { > // find loaded meshes > std::set<Mesh*> lLoadedMeshes; > { > // some calculations that fill lLoadedMeshes > } > > if(lLoadedMeshes.empty()) > { > break; > } > > // find loadable scenes that uses the already loaded meshes > std::set<Scene*> lLoadableScenes; > { > // some calculations that fill lLoadableScenes > // it uses the result of lLoadedMeshes > } > > > if(lLoadedScenes.empty()) > > { > > break; > > } > > // and so on.. > } The whole point of your scheme is to skip subsequent code if you encounter some sort of error. Therefore, this will do nicely: { std::set<Mesh*> lLoadedMeshes; if (!find_loaded_meshes(lLoadedMeshes)) { // complain and return or throw } std::set<Scene*> lLoadableScenes; if (!find_loadable_scenes(lLoadableScenes, lLoadedMeshes)) { // complain and return or throw } // and so on.. } bool find_loaded_meshes(std::set<Mesh*> & _meshes) { // some calculations that fill _meshes if (_meshes.empty()) { return false; } // do more return true; } bool find_loadable_scenes(std::set<Scene*> & _scenes, std::set<Mesh*> const & _meshes) { { // some calculations that fill lLoadableScenes // it uses the result of _meshes } if (_scenes.empty()) { return false; } // do more return true; } You said before that splitting things into multiple functions reduced readability. My version is more readable for several reasons. Each function has a single purpose rather than one function doing many things. Notice that I removed some comments in your version because the function names obviated them (self- documenting code). Finally, the high level logic, in the initial block, is clearer, while the low level logic is segregated into separate functions. If you'd prefer to avoid early returns, "else" is handy: { std::set<Mesh*> lLoadedMeshes; if (!find_loaded_meshes(lLoadedMeshes)) { // complain and return or throw } else { std::set<Scene*> lLoadableScenes; if (!find_loadable_scenes(lLoadableScenes, lLoadedMeshes)) { // complain and return or throw } // and so on.. } } _____ Rob Stewart robert.stewart@sig.com 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Then concerning It also supposes that the find_loaded_meshes function name is a good one. PS : --In the case of the "find Loaded Meshes", in fact I was thinking to a very special case of a memory manager of a 3D game that is -during loading threaded resources- updating some data before final cleaning of its state. It just means that there is already a findLoadedMeshes() function, for the user of the class, and it uses the cleaned set of information, not the 'dirty' one being loaded as supposed in my example.-- So the name of the function, must be chosen carefully to suppress any doubt from the reader. --- En date de : Mar 8.9.09, Stewart, Robert <Robert.Stewart@sig.com> a écrit : De: Stewart, Robert <Robert.Stewart@sig.com> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: "boost@lists.boost.org" <boost@lists.boost.org> Date: Mardi 8 Septembre 2009, 7h14 Pierre Morcello wrote: > > Thanks Michael, I did not think sooner to the 'else if'. But I like the "else if" version better, too. > there is one problem with the 'else if' : you can not do > calculations between the tests. > > When I work often my code looks like : > > // retrieve meshes from prototype > Breakable > { > // find loaded meshes > std::set<Mesh*> lLoadedMeshes; > { > // some calculations that fill lLoadedMeshes > } > > if(lLoadedMeshes.empty()) > { > break; > } > > // find loadable scenes that uses the already loaded meshes > std::set<Scene*> lLoadableScenes; > { > // some calculations that fill lLoadableScenes > // it uses the result of lLoadedMeshes > } > > > if(lLoadedScenes.empty()) > > { > > break; > > } > > // and so on.. > } The whole point of your scheme is to skip subsequent code if you encounter some sort of error. Therefore, this will do nicely: { std::set<Mesh*> lLoadedMeshes; if (!find_loaded_meshes(lLoadedMeshes)) { // complain and return or throw } std::set<Scene*> lLoadableScenes; if (!find_loadable_scenes(lLoadableScenes, lLoadedMeshes)) { // complain and return or throw } // and so on.. } bool find_loaded_meshes(std::set<Mesh*> & _meshes) { // some calculations that fill _meshes if (_meshes.empty()) { return false; } // do more return true; } bool find_loadable_scenes(std::set<Scene*> & _scenes, std::set<Mesh*> const & _meshes) { { // some calculations that fill lLoadableScenes // it uses the result of _meshes } if (_scenes.empty()) { return false; } // do more return true; } You said before that splitting things into multiple functions reduced readability. My version is more readable for several reasons. Each function has a single purpose rather than one function doing many things. Notice that I removed some comments in your version because the function names obviated them (self- documenting code). Finally, the high level logic, in the initial block, is clearer, while the low level logic is segregated into separate functions. If you'd prefer to avoid early returns, "else" is handy: { std::set<Mesh*> lLoadedMeshes; if (!find_loaded_meshes(lLoadedMeshes)) { // complain and return or throw } else { std::set<Scene*> lLoadableScenes; if (!find_loadable_scenes(lLoadableScenes, lLoadedMeshes)) { // complain and return or throw } // and so on.. } } _____ Rob Stewart robert.stewart@sig.com 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Pierre Morcello wrote:
0/ just a side note.
[snip]
So the name of the function, must be chosen carefully to suppress any doubt from the reader.
Of course.
1/ One side effect in your approach is that it forces the user to declare the function in the .h. If there is no use to reuse the code (because it is extremely specific to the function), then you are polluting the .h with things that are not information specific to the class, but only to one function.
Not true. Even if the original code in question is in a member function, the other functions need not be so.
2/ If I have to declare the function in the .h, I may end writing : "void _myfuntion_findLoadedMeshes()" in private, with a doxygen description on top of it. Why such a description if the code is 'self explanatory'? The reason is : each of my function got a set of preconditions to tests, sometimes post conditions, and I would not ask someone to maintain a system without these informations. Without these comments, I suppose I will also end asserting everything in the code I already already tested back in the 'parent' function. As a matter of fact I have already seen guys who were testing a boolean member as a precondition to see if the function was called just after the 'supposed previous call'. So there is a need to restrain the use of the 'sub-function' to the 'parent function' only.
If the subfunction must be a member, then it must be declared in the class definition. I don't begin to understand why it must be documented for Doxygen. Implementation details should not be documented for users. 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.
My conclusion on this 'keep the h clean' part is : if the 'sub-part' is big or to be reused, 'function split' (as you proposed) or even aggregation is the way to go. If the sub-part is very specific and 'middle-big', a local struct with methods is much nicer. In the last case, if the 'sub-part' is little and very specific, you will appreciate the 'Breakable' idiom.
I haven't argued that your "Breakable" idiom is a bad idea for all cases, but I did address the specific example you cited and showed a very readable alternative that avoided the "Breakable" approach.
3/ possible errors creation during subfunction writing. When you write the 'Breakable', you are only writing 1 line. It is very hard to write something wrong at that level. When you declare the subfunctions, you have to declare the parameters, also gives them meaningfull names. Most of the time, let say I have between 2 or 3 parameters to give to the subfunction. 1 time out of 3 I have a std container to transmit. Someone with less experience than me (or myself when I am tired) could write "bool find_loaded_meshes(std::set<Mesh*> _meshes)" and forgetting the & in the definition. Then copy/pasting the result to write quickier its declaration, it stays the same. Then, if the function is just checking things inside the container, you got a real performance hit for free. Otherwise you will find this error soon when it bugs. So conclusion on that point is : this will take you more time and length to code, and is more prone to some errors (even if they are rare / not tragic).
I've never found such problems to be common among my peers or in my own code. If your cadre is prone to such things, then it is a real concern. However, your approach increases coupling and decreases cohesion. There are always tradeoffs and one must balance the forces as appropriate to a given context.
4/ People write a function when they need one, not in order to manage a syntax problem. You supposed I don't know when I should write a function. Well, as a matter of fact, the problem is the other way round : I am studying the case when the user knows he does not need any function at that point, and he only needs syntactic sugar.
I write a function whenever it makes my code clearer, reduces coupling, increases cohesion, increases reuse, etc. Syntactic sugar is a nice thing to have when it doesn't cause cavities. _____ Rob Stewart robert.stewart@sig.com 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.
At Stewart Roberts, about "embedded if else" vs "Breakable idiom". (I answer in a separated mail, because this may also interest other people, more than the previous one). You proposed the "embedded if{}else{}" solution. If I was fully pleased with it, I would not have dare to propose the 'Breakable' idiom solution :-). My concerns are : 1 When you are embedding if/ else, you got quickly more tabs/space to manage. 2 When you are embedding more than 4 if/else, you have to be more careful to the right side of your line. Nobody like to scroll left right, and it is harder to print or display on your website ^^. Even more if you got a 10' screen. 3 When you are using the 'Breakable' idiom, your code is vertically structured, and looking extremely homogeneous. 4 With the 'Breakable' idiom, 'else' is implicit. As a consequence, you will have less lines (unless you are using "}else{" like unix user, in which case it is the same length). 5 The "test", "fail case" and the "ok case" looks more contiguous. These are not separated by the other tests or the "}else{". There are less "visuals parasite" between them. Have a look : if(t1) { if(t2) { if(t3) { if(t4) { if(t4) { } else { } } else { } } else { } } else { } } else { } Breakable { if(!t1) { break; } if(!t2) { break; } if(!t3) { break; } if(!t4) { break; } if(!t5) { break; } } You can also imagine 1 or 2 lines of code between each test and case, to get an idea of the use. 6 The breakable code is easier to maintain : you can add a test and a else without "re-tabbing" the code, and also without needing to scroll up/down to make the visual correspondance between a "if " and a "else" that are separated by 4 tests. As a consequence, I consider The 'Breakable idiom' often improves readability for theses tasks, over the embedded if{}else{}. Also, compared to the expanded version (for(bool executed=false; executed!=true; executed =true) or do{...}while(false), the 'Breakable macro' tells why it is here : it suppresses doubts. I suppose most of my coworker would ask me why there is a "do{...}while(false)" in some code, while on the contrary, it took them no pain to understand the use and the meaning (when they read it in someone else code) of the macro. Thanks for your time, Best regards, Pierre Morcello
I have skimmed this thread and wanted to offer my opinion. I do not see code like the OP has provided in what I write, so to me this is a solution looking for a problem. Like most, I prefer small blocks of code with simple patterns such as: type method(args) { if (cond(args)) return foo(args); intermediate val = calc(args); return result(val, args); } The case for 'Breakable' seems to be to support a code style that is, pardon me, quite archaic. As has been noted in this thread, if the code was written to be modular and self-documenting to start with, there is no need for 'breakable'. 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. 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. I too second the idea of perhaps extending Boost.ScopedExit, which I personally have used to create strong exception-safe code without having to make a dozen auxiliary CIRA structures. 'Breakable' is a way to create long methods, or dealing with many nested conditionals. These are not needed in the first place. If you are at greater than 2 levels of indentation, that is a sign that you need to refactor, not a sign that you need to make the function 'Breakable'. Regards, Christian. On Wed, Sep 9, 2009 at 9:30 AM, Pierre Morcello <pmorcell-cppfrance@yahoo.fr
wrote:
At Stewart Roberts, about "embedded if else" vs "Breakable idiom".
(I answer in a separated mail, because this may also interest other people, more than the previous one).
You proposed the "embedded if{}else{}" solution. If I was fully pleased with it, I would not have dare to propose the 'Breakable' idiom solution :-). My concerns are :
1
When you are embedding if/ else, you got quickly more tabs/space to manage.
2
When you are embedding more than 4 if/else, you have to be more careful to the right side of your line. Nobody like to scroll left right, and it is harder to print or display on your website ^^. Even more if you got a 10' screen.
3
When you are using the 'Breakable' idiom, your code is vertically structured, and looking extremely homogeneous.
4
With the 'Breakable' idiom, 'else' is implicit. As a consequence, you will have less lines (unless you are using "}else{" like unix user, in which case it is the same length).
5 The "test", "fail case" and the "ok case" looks more contiguous. These are not separated by the other tests or the "}else{". There are less "visuals parasite" between them.
Have a look :
if(t1)
{
if(t2)
{
if(t3)
{
if(t4)
{
if(t4)
{
}
else
{
}
}
else
{
}
}
else
{
}
}
else
{
}
}
else
{
}
Breakable
{
if(!t1)
{
break;
}
if(!t2)
{
break;
}
if(!t3)
{
break;
}
if(!t4)
{
break;
}
if(!t5)
{
break;
}
}
You can also imagine 1 or 2 lines of code between each test and case, to get an idea of the use.
6
The breakable code is easier to maintain : you can add a test and a else without "re-tabbing" the code, and also without needing to scroll up/down to make the visual correspondance between a "if " and a "else" that are separated by 4 tests.
As a consequence, I consider The 'Breakable idiom' often improves readability for theses tasks, over the embedded if{}else{}.
Also, compared to the expanded version (for(bool executed=false; executed!=true; executed =true) or do{...}while(false), the 'Breakable macro' tells why it is here : it suppresses doubts. I suppose most of my coworker would ask me why there is a "do{...}while(false)" in some code, while on the contrary, it took them no pain to understand the use and the meaning (when they read it in someone else code) of the macro.
Thanks for your time,
Best regards,
Pierre Morcello
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Christian Schladetsch wrote:
I have skimmed this thread and wanted to offer my opinion.
I do not see code like the OP has provided in what I write, so to me this is a solution looking for a problem. Like most, I prefer small blocks of code with simple patterns such as:
type method(args) { if (cond(args)) return foo(args); intermediate val = calc(args); return result(val, args); }
The case for 'Breakable' seems to be to support a code style that is, pardon me, quite archaic. As has been noted in this thread, if the code was written to be modular and self-documenting to start with, there is no need for 'breakable'.
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 logic sometimes occur in Windows GUI programming. It seems to me that DirectX API at least in some old versions also tend to cause this kind of logic in the client code. 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. 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. 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. 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: { /* Code */ last if /* block termination condition */ /* More code */ last if /* another block termination condition */ /* The rest of the block code */ } /* All "last" jumps here */ Almost exactly as in Gottlob Frege's hypothetical sample.
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? On a related topic I have just remembered that I have "discovered" another not very common but still recurring control flow construct. In C++ it looks like this: while (true) { /* code */ if (/* above code failed */) continue; /* code */ if (/* failed */) continue; /* more code */ break; } Perl is the only language I know of to have support of this construct almost natively. It has a redo command that restarts current loop iteration and it treats an unnamed block as a loop that is executed once. -- Ilya Bobir
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@sig.com 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.
Stewart, Robert wrote:
Ilya Bobir wrote:
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).
Your answer reminded me talks on why closures should not be added to Java. There is a point that as Java has anonymous classes there really is no use for closures as one can emulate a closure with an anonymous class. While I do think that RAII is a very good approach it just does not do well in case you have to deal with a C style API. Windows API is mostly C style. As well as the old DirectX API. If all APIs were C++ and were codded to support RAII and exceptions programming in C++ would be a lot easier but it is not the case. Some of C++ programmers still have to deal with C APIs and wrapping everything to support RAII is not always the most cost effective approach.
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.
This way you may end up with a lot of functions that are named very similarly and call each other doing only very small pieces of work. While generally it seems to be a good thing when your functions are short when they became too short, because you are blindly adhering to some coding practice, the code looses readability. I think this is a good example were creating a separate subfunction will not make code more readable. I have seen some prominent examples in the Windows source of a code that is hard to understand because a simple thing is performed by a dozen of functions that call each other. It is hard to understand what a separate function does as the code is very tightly coupled but because of some coding convention it is split into different functions. I can not give you a direct link as the Windows source does not seems to be available online, but here is a stack trace of a Windows Shell call: shell32.dll!AicpMsgWaitForCompletion() + 0x36 shell32.dll!AicpAsyncFinishCall() + 0x2c shell32.dll!AicLaunchAdminProcess() + 0x2ee shell32.dll!_SHCreateProcess() + 0x59d0 shell32.dll!CExecuteApplication::_CreateProcess() + 0xac shell32.dll!CExecuteApplication::_TryCreateProcess() + 0x2e shell32.dll!CExecuteApplication::_DoApplication() + 0x3c shell32.dll!CExecuteApplication::Execute() + 0x33 shell32.dll!CExecuteAssociation::_DoCommand() + 0x5b shell32.dll!CExecuteAssociation::_TryApplication() + 0x32 shell32.dll!CExecuteAssociation::Execute() + 0x30 shell32.dll!CShellExecute::_ExecuteAssoc() + 0x82 shell32.dll!CShellExecute::_DoExecute() + 0x4c shell32.dll!CShellExecute::s_ExecuteThreadProc() + 0x25 shlwapi.dll!WrapperThreadProc() + 0x98 kernel32.dll!@BaseThreadInitThunk@12() + 0x12 ntdll.dll!__RtlUserThreadStart@8() + 0x27 The call is supposed to start a process. As you can see method names are very similar and, I believe, unless you are familiar with the code it is not obvious what each function does and unless you have a stack trace it is not even obvious the order in which the functions are called. This stack trace is a quote from this article: http://www.codeproject.com/KB/vista-security/UAC__The_Definitive_Guide.aspx
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.
Totally agreed. Note that not all the code out there is a proper C++ style and there are billions lines of code already written.
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++. ;)
The point it that the breakable is a control flow construct already "accepted" by some languages. And as such it can be treated as a control flow pattern. Not as common as "for" but still a control flow pattern, not a "bad coding style". -- Ilya Bobir
Ilya Bobir wrote:
Stewart, Robert wrote:
Ilya Bobir wrote:
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).
While I do think that RAII is a very good approach it just does not do well in case you have to deal with a C style API. Windows API is mostly C style. As well as the old DirectX API.
I do whatever I can to avoid dealing with C APIs.
If all APIs were C++ and were codded to support RAII and exceptions programming in C++ would be a lot easier but it is not the case. Some of C++ programmers still have to deal with C APIs and wrapping everything to support RAII is not always the most cost effective approach.
I much prefer RAII even when not dealing with exceptions. It makes the code clearer.
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.
This way you may end up with a lot of functions that are named very similarly and call each other doing only very small pieces of work. While generally it seems to be a good thing when your functions are short when they became too short, because you are blindly adhering to some coding practice, the code looses readability.
That can happen, but its rare.
I have seen some prominent examples in the Windows source of a code that is hard to understand because a simple thing is performed by a dozen of functions that call each other. It is hard to understand what a separate function does as the code is very tightly coupled but because of some coding convention it is split into different functions. I can not give you a direct link as the Windows source does not seems to be available online, but here is a stack trace of a Windows Shell call:
shell32.dll!AicpMsgWaitForCompletion() + 0x36 shell32.dll!AicpAsyncFinishCall() + 0x2c shell32.dll!AicLaunchAdminProcess() + 0x2ee shell32.dll!_SHCreateProcess() + 0x59d0 shell32.dll!CExecuteApplication::_CreateProcess() + 0xac shell32.dll!CExecuteApplication::_TryCreateProcess() + 0x2e shell32.dll!CExecuteApplication::_DoApplication() + 0x3c shell32.dll!CExecuteApplication::Execute() + 0x33 shell32.dll!CExecuteAssociation::_DoCommand() + 0x5b shell32.dll!CExecuteAssociation::_TryApplication() + 0x32 shell32.dll!CExecuteAssociation::Execute() + 0x30 shell32.dll!CShellExecute::_ExecuteAssoc() + 0x82 shell32.dll!CShellExecute::_DoExecute() + 0x4c shell32.dll!CShellExecute::s_ExecuteThreadProc() + 0x25 shlwapi.dll!WrapperThreadProc() + 0x98 kernel32.dll!@BaseThreadInitThunk@12() + 0x12 ntdll.dll!__RtlUserThreadStart@8() + 0x27
The call is supposed to start a process. As you can see method names are very similar and, I believe, unless you are familiar with the code it is not obvious what each function does and unless you have a stack trace it is not even obvious the order in which the functions are called.
Without details on how complex those functions are, neither of us can comment on this example. If the functions in that stack trace are non-trivial, if they are reused, etc., the factorization was a good idea. If they are tiny functions that take lots of arguments, then the factorization was a bad idea.
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.
Totally agreed. Note that not all the code out there is a proper C++ style and there are billions lines of code already written.
When maintaining code, one often has the choice of inserting something like the "breakable" approach, refactoring, adding RAII, etc.
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++. ;)
The point it that the breakable is a control flow construct already "accepted" by some languages. And as such it can be treated as a control flow pattern. Not as common as "for" but still a control flow pattern, not a "bad coding style".
"That other languages do something doesn't mean it is a good idea." Just because it is codified in other languages as a control flow pattern doesn't mean it isn't bad coding style. We seem to be agreeing violently that the "Breakable Idiom" may make some code clearer but that there are many alternatives that bring other benefits, so I'll not say more. The question is whether Boost will accept it. The only way to really know the answer to that question is to have it reviewed. _____ Rob Stewart robert.stewart@sig.com 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.
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
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@yahoo.fr> 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
Answer to Christian Schaldetsh;
"This position you have that some of us are arguing emotively and others reasonably seems somewhat arbitrary. "
Sorry, I was refering to comments or claims inside some answers, not to people, sincerly. (source :"I am surprised to find so many comments like..."). In the case of your answer, I was too lazy to answer you sooner on the facts that you presented, but I was also feeling very uneasy with your logic. I am sorry you had to re-wrote your answer because of my lack of answer. If it seems arbitrary, then I will explain why things could not discussed anymore, because of the way you presented them. I will also present my point of view on your presentation/answer.
"I claimed that the style supported/encouraged by 'Breakable' is archaic.." You seem to think that archaic is bad. Well, as a matter of fact there is no logic telling you that something archaic is bad : do you think everything new is good ? You see, this is not good for a discussion.
"We have ways to do that in C++ using RIAA and exceptions. We also have Boost.ScopedExit." "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."
There are 2 points here. First point is something like "we already have very good technologies to do that". I agree that RAII, exceptions and functions are a very handy set of tools to do handle conditional branching. Unfortunately, this is not enough to jump to the conclusion : to go from city A to city B, I can take the car, the plane or the train. If it is Paris -> New York I will prefer the plane, if it is Paris -> Strasbourg, I will prefer the train. So for each very good technology there may be a slightly different usage, even if the aim is globally the same. In the current case, I don't see in your point why the presence of the other technology should make Breakable not more appropriate in some cases. How I am supposed to answer when I do not understand your logic? Second point is something like (correct me if I am wrong) "Breakable can be seen as a somewhat equivalent to function. I claim functions are as much readable as Breakable. As a consequence, it is all about style." I did, in a previous answer, gives some other reason in my opinion to prefer Breakable in some case : productivity, simplicity and maintanability. As you code less, there are less prone to some errors. As there are less lines, you can follow more code in one glimpse. As you do not need to carefully choose a function name, but instead may use a traditionnal comment, or consider the code trivial, you don't spend time looking for it (you won't introduce doubt in the head of the maintainer of the code). You also do not need to maintain the changes to function prototypes, and also to maintain precondition and post condition tests in the function. This simplicity is understandable by most people. These are facts that I see, and this was good material if you wanted to argue (ex of sentence you could have written : "I would not use precondition tests in that case ..." ). Then concerning readability only, you seem to evaluate readability magically without explaining your selection criteria. At least I tried the best I could to present some facts, and you just stepped over them without reason. How am I supposed to answer to such points? So, I supposed it was better not to answer. I am very new to these forums, and I try my best to do things readable and understandable for people. Even now I am often misunderstood. But if I were justifying my proposition like you judged it, how could we ever find the solution to the dilemma ? I hope you understand why I was so uneasy with your answer. I am ok to change my mind on any subject (including the Breakable of course), as long as you are enough logical to prove me you are right (or I am wrong :-)). In all cases, I appreciate the efforts you made to explain your point of view a second time. I will, on my side, try to make myself clearer when I say something that could be ambiguous I apology if anyone else felt it as a personnal attack, this was absolutely not intended. I hope this is clearer and closed. Now on the other elements of your answer :
"it could be said to support old Win32 coding style, or old DirectX coding style, but these are terrible things to want to support!"
I agree with you, for that reason, I did not speak of Win32 and neither used it as example (by the way, DirectShow is much worse than any dxsdk I met).
"I think that 'Breakable' encourages bad style." Do you mean that it would always be "bad style" ( <=> Breakable is never useful / is always bad) ? Or do you mean that it can be misused too easily ?
Best regards, Pierre Morcello --- En date de : Mer 9.9.09, Christian Schladetsch <christian.schladetsch@gmail.com> a écrit : De: Christian Schladetsch <christian.schladetsch@gmail.com> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: boost@lists.boost.org Date: Mercredi 9 Septembre 2009, 16h24 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@yahoo.fr> 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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Pierre Morcello wrote:
At Stewart Roberts, about "embedded if else" vs "Breakable idiom".
You proposed the "embedded if{}else{}" solution. If I was fully pleased with it, I would not have dare to propose the 'Breakable' idiom solution :-). My concerns are :
When you are embedding if/ else, you got quickly more tabs/space to manage.
When you are embedding more than 4 if/else, you have to be more careful to the right side of your line. Nobody like to scroll left right, and it is harder to print or display on your website ^^. Even more if you got a 10' screen.
You're assuming the need to nest each if/else, which is often not required. You're also addressing this approach in isolation, when it is often combined with factoring out subfunctions.
When you are using the 'Breakable' idiom, your code is vertically structured, and looking extremely homogeneous.
That is a nice benefit.
The "test", "fail case" and the "ok case" looks more contiguous. These are not separated by the other tests or the "}else{". There are less "visuals parasite" between them.
Errors are often handled by throwing exceptions. When they aren't, they may be handled by early returns. When that doesn't apply, they are rightfully relegated to the end of the function out of the main code path. Consequently, I consider this a straw man argument.
Have a look :
Perhaps you format your code as you showed it, but I think you've indented to try to make things look as bad as possible. I certainly don't write code as you did. I removed the excess blank lines to present things better.
if(t1) { if(t2) { if(t3) { if(t4) { if(t4) { } else { } } else { } } else { } } else { } } else { }
Breakable
{ if(!t1) { break; } if(!t2) { break; } if(!t3) { break; } if(!t4) { break; } if(!t5) { break; } }
As written, it would appear that there's nothing to be done following the "breakable" scope, so I would just change "break" to "return" and be done with it.
The breakable code is easier to maintain : you can add a test and a else without "re-tabbing" the code, and also without needing to scroll up/down to make the visual correspondance between a "if " and a "else" that are separated by 4 tests.
Your example is a worst case which I rarely see. Early returns and subfunctions easily restructure most of the formatting issues you note and can increase cohesion and decrease coupling.
As a consequence, I consider The 'Breakable idiom' often improves readability for theses tasks, over the embedded if{}else{}.
If you often encounter such situations, then you may well be writing your logic in a way that makes things more awkward than necessary. Nevertheless, if that's the way you feel presents your logic most clearly, your "breakable" approach does offer an option.
Also, compared to the expanded version (for(bool executed=false; executed!=true; executed =true) or do{...}while(false), the 'Breakable macro' tells why it is here : it suppresses doubts. I suppose most of my coworker would ask me why there is a "do{...}while(false)" in some code, while on the contrary, it took them no pain to understand the use and the meaning (when they read it in someone else code) of the macro.
If do { } while (false) is confusing, then you have bigger issues. _____ Rob Stewart robert.stewart@sig.com 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.
Hi, ----- Original Message ----- From: "Pierre Morcello" <pmorcell-cppfrance@yahoo.fr> To: <boost@lists.boost.org> Sent: Sunday, September 06, 2009 7:58 PM Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakablelibrary? Hi, there is no difference. Indeed, the macro as I use it right now is even less optimised than a GOTO or a do...while(false) : it's currently just a simple 'for' loop in a macro.. The aim is to make code more readable. A goto is a pain to manage when you use a lot this 'breakable' structure. The fact that it is easy to use and readable makes it easier to use a lot. In the end, I happen myself to use it lot more than I thougth I would at first. That is the main reason why I am proposing it here.
Both are probably shorter to write. Yes, although someone using such library may redefine the macro as he wishes : e.g. #define Breakable BOOST_BREAKABLE I am just conforming to BOOST coding style.
Pierre --- En date de : Dim 6.9.09, Sebastian Redl <sebastian.redl@getdesigned.at> a écrit : De: Sebastian Redl <sebastian.redl@getdesigned.at> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: boost@lists.boost.org Date: Dimanche 6 Septembre 2009, 9h10 Pierre Morcello wrote:
Hello,
I propose a set of macros that allow to break anywhere. Example of use of the main macro :
// do something... BOOST_BREAKABLE { if (test1) { break; } if (test2)
{
break;
}
std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } // here the program continues ...
Is there any interest in such a library?
What's the difference between this and a goto? Or a do ... while(false); loop? Both are probably shorter to write. Sebastian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost The isea to rerplace a goto with a loop and a break is interesting, but I agree with Sebastian, why your macro is more readable than do { if (test1) { break; } if (test2) { break; } std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } while(false); or for (bool executed=false;!executed;executed=true) { if (test1) { break; } if (test2) { break; } std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } I'll not include a header library just for this. Best, Vicente
On Sep 6, 2009, at 3:48 PM, vicente.botet wrote:
Hi, ----- Original Message ----- From: "Pierre Morcello" <pmorcell-cppfrance@yahoo.fr> To: <boost@lists.boost.org> Sent: Sunday, September 06, 2009 7:58 PM Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakablelibrary?
Hi, there is no difference.
Indeed, the macro as I use it right now is even less optimised than a GOTO or a do...while(false) : it's currently just a simple 'for' loop in a macro..
The aim is to make code more readable. A goto is a pain to manage when you use a lot this 'breakable' structure.
If you use a lot of that 'breakable' structure - or its concrete counterparts (single-iterative for-loops or do-while's) - you might consider an overhaul of your code. I have written a lot of abstract machines and compilers so I am aware of the (quite few) cases where goto's and such use of breaks are justified, but such cases are rare. 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 :-)
The fact that it is easy to use and readable makes it easier to use a lot. In the end, I happen myself to use it lot more than I thougth I would at first. That is the main reason why I am proposing it here.
Both are probably shorter to write. Yes, although someone using such library may redefine the macro as he wishes : e.g. #define Breakable BOOST_BREAKABLE I am just conforming to BOOST coding style.
A comment regarding interest: no, I am not interested. As sebastian pointed out, "do { .... } while (false);" is simple enough, and ugly enough to at least make the coder think twice before using it :-) /David
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.
Anyway, could you be more precise concerning the overhaul? Pierre --- En date de : Dim 6.9.09, David Bergman <David.Bergman@bergmangupta.com> a écrit : De: David Bergman <David.Bergman@bergmangupta.com> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakablelibrary? À: boost@lists.boost.org Date: Dimanche 6 Septembre 2009, 12h56 On Sep 6, 2009, at 3:48 PM, vicente.botet wrote:
Hi, ----- Original Message ----- From: "Pierre Morcello" <pmorcell-cppfrance@yahoo.fr> To: <boost@lists.boost.org> Sent: Sunday, September 06, 2009 7:58 PM Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakablelibrary?
Hi, there is no difference.
Indeed, the macro as I use it right now is even less optimised than a GOTO or a do...while(false) : it's currently just a simple 'for' loop in a macro..
The aim is to make code more readable. A goto is a pain to manage when you use a lot this 'breakable' structure.
If you use a lot of that 'breakable' structure - or its concrete counterparts (single-iterative for-loops or do-while's) - you might consider an overhaul of your code. I have written a lot of abstract machines and compilers so I am aware of the (quite few) cases where goto's and such use of breaks are justified, but such cases are rare. 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 :-)
The fact that it is easy to use and readable makes it easier to use a lot.. In the end, I happen myself to use it lot more than I thougth I would at first. That is the main reason why I am proposing it here.
Both are probably shorter to write. Yes, although someone using such library may redefine the macro as he wishes : e.g. #define Breakable BOOST_BREAKABLE I am just conforming to BOOST coding style.
A comment regarding interest: no, I am not interested. As sebastian pointed out, "do { .... } while (false);" is simple enough, and ugly enough to at least make the coder think twice before using it :-) /David _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
Pierre Morcello wrote:
Anyway, could you be more precise concerning the overhaul?
Simply put, the fact that you often have the situation where you have an otherwise regular block of code, and you suddenly want to jump to the end of it, suggests that you're writing poorly structured code. Why can't you use a proper if-statement for this construct? Why not use a function with early returns? You say that your macro makes the code more readable, but what probably would make it even more readable would be restructuring it. Sebastian
On Sun, Sep 6, 2009 at 8:56 PM, David Bergman < David.Bergman@bergmangupta.com> wrote:
..., just an advice from an old fart, having wrestled, and eventually mastered, C++ for the last 20 years :-)
Congratulations, I find mastery continually evades me - the closer I seem to get, the more it slips away! - Rob.
I find mastery continually evades me - the closer I seem to get, the more it slips away!
- Rob.
I completely agree. Zeno's paradox may be true after all. Kenneth -- View this message in context: http://www.nabble.com/-Boost.Breakable--Any-interest-in-a-Boost-Breakable-li... Sent from the Boost - Dev mailing list archive at Nabble.com.
vicente.botet wrote
"The isea to rerplace a goto with a loop and a break is interesting, but I agree with Sebastian, why your macro is more readable than"
For 1 'breakable struct', there is yes, not much use. But when you begin to embbed one within another, it can be nicer to read.
"I'll not include a header library just for this."
Thanks for your point of view. Someone else made this remarks too. My answer is : I consider that not everyone is aware of this useful struct. This is the same for a boost::non-copyable. You can easily write the private copy constructor & so on yourself without boost. But the fact that it exists, will give a more broader spread of this simple idea. And good if people wants to write their own. But as you can see, even on this forum, some people never thought of this use of a simple breakable part.
Sebastian Redl wrote : "You say that your macro makes the code more readable, but what probably would make it even more readable would be restructuring it."
You can have a look at the example of pseudo code of a reading of a xml I posted to choose which version you prefer.
David Bergman wrote: "I would probably listen more to a very experienced developer than a newbie.." Well the fact is I try (as more as I can) to listen always with maximum concentration to whoever speaks to me.
On a more serious subject ;-), David Bergman wrote: 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.
Thanks for this point of view. Let me explain mine : you are telling basically SESE(single entry single out) is good for readability, and the other things are not that good. Well (long ago), GOTO was a pain to maintain in less recent languages. Programmers made a lot of efforts to get rid of it, and 'won' through the wide spread of SESE as a rule of thumb. Now, goto are never to be seen in C++ (sincerely I have never seen one in C++), so I can say we are 'freed' of this kind of problems. So it is ok to do break. I worked with pure SESE during 7 years, (image processing, GUI, reflection systems,...). Then I tried to change my habits by using 'breaks' in loops. Things were better most of the time. That is how I eventually tried the 'brekable struct'. Since I use it, I find things are organized even nicer in my code. Best regards, Pierre --- En date de : Dim 6.9.09, vicente.botet <vicente.botet@wanadoo.fr> a écrit : De: vicente.botet <vicente.botet@wanadoo.fr> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakablelibrary? À: boost@lists.boost.org Date: Dimanche 6 Septembre 2009, 12h48 Hi, ----- Original Message ----- From: "Pierre Morcello" <pmorcell-cppfrance@yahoo.fr> To: <boost@lists.boost.org> Sent: Sunday, September 06, 2009 7:58 PM Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakablelibrary? Hi, there is no difference. Indeed, the macro as I use it right now is even less optimised than a GOTO or a do...while(false) : it's currently just a simple 'for' loop in a macro... The aim is to make code more readable. A goto is a pain to manage when you use a lot this 'breakable' structure. The fact that it is easy to use and readable makes it easier to use a lot. In the end, I happen myself to use it lot more than I thougth I would at first. That is the main reason why I am proposing it here.
Both are probably shorter to write. Yes, although someone using such library may redefine the macro as he wishes : e.g. #define Breakable BOOST_BREAKABLE I am just conforming to BOOST coding style.
Pierre --- En date de : Dim 6.9.09, Sebastian Redl <sebastian.redl@getdesigned.at> a écrit : De: Sebastian Redl <sebastian.redl@getdesigned.at> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: boost@lists.boost.org Date: Dimanche 6 Septembre 2009, 9h10 Pierre Morcello wrote:
Hello,
I propose a set of macros that allow to break anywhere. Example of use of the main macro :
// do something... BOOST_BREAKABLE { if (test1) { break; } if (test2)
{
break;
}
std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } // here the program continues ...
Is there any interest in such a library?
What's the difference between this and a goto? Or a do ... while(false); loop? Both are probably shorter to write. Sebastian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost The isea to rerplace a goto with a loop and a break is interesting, but I agree with Sebastian, why your macro is more readable than do { if (test1) { break; } if (test2) { break; } std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } while(false); or for (bool executed=false;!executed;executed=true) { if (test1) { break; } if (test2) { break; } std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } I'll not include a header library just for this. Best, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Pierre Morcello wrote:
Hello,
I propose a set of macros that allow to break anywhere. Example of use of the main macro :
// do something... BOOST_BREAKABLE { if (test1) { break; } if (test2)
{
break;
}
std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } // here the program continues ...
Is there any interest in such a library?
Best regards,
Pierre Morcello
I think this is an excellent idea. Though the do...while(false) trick is a rather handy one, I've always felt that it its purpose might not be clear enough, especially to someone who has never encountered it before. However, I agree with Thomas: this is a one-line macro, and it should be portable between all standards compliant C++ compilers. There is simply no need to create a library just for this feature. Perhaps you could expand upon it a bit? Regards, Martin Törnwall
Pierre Morcello wrote:
I propose a set of macros that allow to break anywhere. Example of use of the main macro :
// do something... BOOST_BREAKABLE { if (test1) { break; } if (test2)
{
break;
}
std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } // here the program continues ...
What about using a lambda? [&]() -> void { if(test1) return; if(test2) return; std::cout << "this is never reached if test1==true or test2==true." << std::endl; // do something... }(); That kind of thing can also be made with macros instead of lambdas using a similar technique to that of Boost.ScopeExit. This also has the potential of being able to return values, which can be pretty useful to initialize an object for example.
on Mon Sep 07 2009, Alexander Nasonov <alnsn-AT-yandex.ru> wrote:
Mathias Gaunard wrote:
What about using a lambda? [&]() -> void ... That kind of thing can also be made with macros instead of lambdas using a similar technique to that of Boost.ScopeExit.
Is there still an interest in local fuctions with ScopeExit-like interface?
I'm interested. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams-3 wrote:
on Mon Sep 07 2009, Alexander Nasonov <alnsn-AT-yandex.ru> wrote:
Mathias Gaunard wrote:
What about using a lambda? [&]() -> void ... That kind of thing can also be made with macros instead of lambdas using a similar technique to that of Boost.ScopeExit.
Is there still an interest in local fuctions with ScopeExit-like interface?
I'm interested.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'm interested too, Vicente -- View this message in context: http://www.nabble.com/-Boost.Breakable--Any-interest-in-a-Boost-Breakable-li... Sent from the Boost - Dev mailing list archive at Nabble.com.
Thank you for this suggestion. This is extremely interesting and I did not consider it myself before (because I never used lambda before). Right now, I am mainly unsure about :
the compiler supports for the lambda the clarity of the syntax, simplicity of use.
Because of the 'return value feature' that you described, It looks like there is something to dig there. For that reason, let me thank you a lot. I will take some time to study it, so that I will be able to share a more precise point of view about this (given my current schedule, it can take one week). Best regards, Pierre Morcello --- En date de : Lun 7.9.09, Mathias Gaunard <mathias.gaunard@ens-lyon.org> a écrit : De: Mathias Gaunard <mathias.gaunard@ens-lyon.org> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library? À: boost@lists.boost.org Date: Lundi 7 Septembre 2009, 15h02 Pierre Morcello wrote:
I propose a set of macros that allow to break anywhere. Example of use of the main macro :
// do something... BOOST_BREAKABLE { if (test1) { break; } if (test2)
{
break;
}
std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } // here the program continues ...
What about using a lambda? [&]() -> void { if(test1) return; if(test2) return; std::cout << "this is never reached if test1==true or test2==true." << std::endl; // do something... }(); That kind of thing can also be made with macros instead of lambdas using a similar technique to that of Boost.ScopeExit. This also has the potential of being able to return values, which can be pretty useful to initialize an object for example. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (20)
-
Alexander Nasonov -
Christian Schladetsch -
David Abrahams -
David Bergman -
GMan -
Gottlob Frege -
Ilya Bobir -
Martin Törnwall -
Mathias Gaunard -
Michael Caisse -
muhammadchang -
OvermindDL1 -
Pierre Morcello -
Robert Jones -
Sebastian Redl -
Stefan Strasser -
Stewart, Robert -
Thomas Klimpel -
Vicente Botet Escriba -
vicente.botet