On Wed, Dec 2, 2009 at 2:23 PM, Koen Deforche <[email protected]> wrote: > Hey all, > > 2009/12/1 OvermindDL1 <[email protected]>: >>> On Tue, Dec 1, 2009 at 10:15 AM, hadass yaari <[email protected]> wrote: >>> And I honestly have no clue why Wt uses that nasty, useless SLOT macro >>> either, you *should* just be able to do this since connect just need a >>> nullary function to call, who cares if it is a function pointer, a >>> functor, or any callable, it should just simplify things and just take >>> a Boost.Function, which can accept and use it all (and which it so >>> happens that the under-the-scenes Boost.Signals happens to take, thus >>> Wt is creating some Binds when it is not necessary (wasting time and >>> memory), and just making things all around more difficult then just >>> taking a simple TR1/Boost.Function). >>> pb->clicked().connect(boost::bind(&AddPersonAuto::bla,this,5)); > > It has indeed been a long time since we implemented the Wt signal > interface. I think it is a straightforward change to also support a > generic template function object, next to the current connect methods. > > The current syntax, with an explicit reference to the target object, > does however allow us to implement the stateless slot learning for > EventSignal, and for that reason alone I think we should not make the > template syntax the default. > > The SLOT macro is there for historical reasons (there was a time that > Wt used a Qt-like moc preprocessor), and it indeed does not really > contribute anything. > >> I really mean this too, for example, what if I want to do something like >> this: >> pb->clicked().connect(let(_a=ref(theTest))[if_(_a>0)[bind(AddPersonAuto::bla,val(this),_a++),bind(AddPersonAuto::differentBla,this,_a),--ref(theTest)]]); >> >> To PrettyPrint that from above: >> pb->clicked().connect( >> let(_a=ref(theTest)) >> [ >> if_(_a>0) >> [ >> bind(AddPersonAuto::bla,val(this),_a++), >> bind(AddPersonAuto::differentBla,this,_a), >> --ref(theTest) >> ] >> ] >> ); >> >> Which would be the same thing as this: >> void AddPersonAuto::doAction(void) >> { >> int a = theTest; >> if(theTest>0) >> { >> bla(a++); >> differentBla(a); >> --theTest; >> } >> } >> pb->clicked().connect(SLOT(this, AddPersonAuto::doAction)); >> >> Which is of course a *lot* more wordy (and yes I know the example is >> not the best designed, I am just showing some programming styles I >> use, and yes, that is valid C++). > > I happened to have read that the latest gcc release has c++0x lambda > support. Have you any experience with it? I sure hope it will look a > lot nicer than this Boost.Lambda hack :-)
Actually this is Boost.Phoenix, not Boost.Lambda. Phoenix re-implements C++ in C++ in a lazy manner. Boost.Lambda and Lambda in the C++1x spec only work for simple things, no real flow control, where Boost.Phoenix supports a *HUGE* amount more. Boost.Phoenix replaces Boost.Lambda, Boost.Bind, and a few other things, it does it all. Yes, I love it, it simplifies *so* much of my code. :) One other nice thing in Boost.Phoenix, even parts of it can be lazy within the lazy bits and so on and so forth, it is *very* powerful. :) Boost.Phoenix1 has been in Boost since 1.33 or so, Boost.Phoenix2 has been in Boost since 1.40, and Boost.Phoenix3 is currently being made, they are backwards compatible in syntax, and each new version supports a great deal more. Believe me, Boost.Lambda and C++1x Lambda have nothing Phoenix. :) And yes, I have been thinking of fixing the class and giving a patch (although no clue how to do patches in GIT, may just send a Universal style diff). ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
