Boost logo

Boost :

Subject: Re: [boost] [Review] Phoenix review starts today, September 21st
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2008-10-01 09:17:15


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk