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.
See: http://goo.gl/uCJuv
- 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?
Thanks, Vicente