Subject: Re: [boost] [Review] Phoenix V3: Mini-review starts February 20th
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-02-26 10:23:22
On Saturday, February 26, 2011 02:36:02 PM Vicente Botet wrote:
> Thomas Heller-7 wrote:
> > On Saturday, February 26, 2011 08:59:06 AM Vicente Botet wrote:
> >> Hartmut Kaiser wrote:
> >> > Hi all,
> >> >
> >> > Thomas Heller worked hard to address the outstanding issues of the
> >> > original
> >> > Phoenix review. He ported Phoenix to Boost.Proto. As mandated by the
> >> > original Boost review, we will conduct a mini-review of his Phoenix
> >> > V3 library.
> >> Hello,
> >> As the documentation don't states explicitly what has been changed,
> >> could you give the links where we can find how the issues
> >> - the breaking interface changes from v2
> > The result_of protocol. Apart from phoenix::function, the frontend API
> > didn't change, phoenix::function now only recognizes Function objects
> > conforming to the result_of protocol.
The change is not documented anywhere specifically, but phoenix::function is
documented here: http://goo.gl/u6mUk
> >> - the migration path from boost::bind and lambda to Phoenix
> >> - how the interoperability with std::bind is solved (result_of
> >> semantics)
> > The interoperability is fully given, all tests from the bind testsuite
> > pass.
Is mentioned here: http://goo.gl/WH5vy
> >> - C++0x features such as rvalue references and variadic templates
> > None of these techniques were implemented.
> >> - the new extensibility mechanism
> > This is documented.
> >> - unified placeholders and interoperability issues with other
> >> Proto-based
> >> DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive)
> > Unified palceholders are documented. Interoperability with other
> > Proto-based
> > DSELs comes naturally with the use of proto.
Unified placeholders: http://goo.gl/opzHj
The interoperability is currently not documented anywhere ... I still have
to figure that one out myself ... It is possible though, but probably is
more proto related ... maybe Eric can say something about that.
> >> - compile times
> > This is probably the weakest part of Phoenix V3 at the moment. Compile
> > times
> > are slightly higher than with Phoenix V2. Keep in mind though, that
> > Phoenix
> > V3 is, due to proto, able to do more. More features come at a price.
Yeah, for compiles, get bigger machines and you won't notice them ;)
> >> have been addressed without taking too much time?
> > Hope that helps!
> Yes it helps, but what I was requesting for was if you could, please,
> give the links to the documentation where all these points are
> documented, so people will loss less time reviewing the documentation?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk