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

Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?
From: Pierre Morcello (pmorcell-cppfrance_at_[hidden])
Date: 2009-09-07 18:43:15

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_at_[hidden]> a écrit :

De: GMan <gmannickg_at_[hidden]>
Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?
À: boost_at_[hidden]
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_at_[hidden]> 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_at_[hidden]> a écrit :
>
> De: Michael Caisse <boost_at_[hidden]>
> Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable
> library?
> À: boost_at_[hidden]
> 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