Hartmut Kaiser wrote:
Hi all,
Please always state in your review, whether you think the library should be accepted as a Boost library!
Additionally please consider giving feedback on the following general topics:
- What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain?
Regards Hartmut Review Manager
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I vote to accept Phoenix. The only comments I have beyond the issues discussed by others: - it would be nice to document which headers are required for the different types and facilities. Or did I miss this somewhere, the only #includes I remember were under the Constant References and Nothing headings - comparison of compiler performance between BLL, Bind... (BLL compile times have a bad rap with my colleagues) - discussion/example using with boost::function, boost::ref/cref,... As others have mentioned, I'd like to see _1, _2, ... rather than the arg1, arg2... ala boost bind and reintroduce the FP background section in the docs. I'm thinking the construct and new_ lazy functions will be particularly useful. Many of our classes end up in containers and or as output from transformed ranges, and end up with many bound static make functions replicating the constructor arguments. Phoenix "construct" makes all those "make"'s redundant. :) Would it be generally useful to have a variant of "new_" that returns a shared_ptr directly? Without it one would need: construct< shared_ptr<X> >( new_<X>( _1, 123, "another arg" ) ) maybe a second template parameter to new_ would allow: new_<X, shared_ptr>(...)? Jeff Flinn