Boost logo

Boost :

From: Eric Niebler (eric_at_[hidden])
Date: 2008-06-30 13:13:31


David Abrahams wrote:
>>> Here are the parts and topics that I see as being in the category:
>>>
>>> result_of
>
> * Too hard to define result<> templates for polymorphic function objects.

Agreed. I've written my own Egg-like function object adaptor to do the
"right thing" with lvalues and rvalues. It lives here:

http://svn.boost.org/trac/boost/browser/branches/proto/v4/boost/proto/detail/poly_function.hpp

It is a polymorphic function object wrapper around a template that
generates monomorphic function objects. (So it's analagous to
mpl::quoteN, which turns a metafunction into a metafunction class.) It
forwards reference-wrapped arguments to the monomorphic implementation
as lvalues, and all others as rvalues.

TODO: replace all Proto's function objects with this wrapper to enforce
consistent behavior. All function objects across Boost that need to make
rvalue/lvalue distinctions would need to be examined for consistency in
this regard. Joel, I'm looking in Fusion's general direction.

> * A whole spate of questions that came up in
> http://article.gmane.org/gmane.comp.lib.boost.devel/173370 were not
> answered with a page of documentation, utility library, or other
> facility. I still don't know what the upshot was

I still don't know either, sadly, but I think a wrapper like the one
above that makes it easy to author polymorphic function objects that
consistently handle lvalues and rvalues is a good first step.

<snip>
>>> lambda/phoenix/bind
>
> * Incompatible placeholders
> * Been waiting for the lambda/phoenix merger forever
> * Lambda has lots of limitations and gotchas that we can improve on now
> * Phoenix 2.0 not in Boost

I've already taken the first and (IMO) most important step here by
porting both Lambda and Phoenix to Proto. My opinion on the unification
of Lambda and Phoenix is that it shouldn't happen. There are too many
subtle differences in semantics. Rather, Lambda should be retired and
Phoenix should be promoted (after being reviewed, etc.). The
placeholders should be Proto terminals shared across Phoenix, Bind,
Xpressive, Spirit and any other library that needs numbered
placeholders. This sort of unification was, after all, one of the major
design goals of Proto in the first place.

Boost.Lambda Proto port:
http://svn.boost.org/trac/boost/browser/branches/proto/v4/libs/proto/example/lambda.hpp

Boost.Phoenix Proto port:
http://svn.boost.org/trac/boost/browser/branches/proto/v4/boost/phoenix

Still TODO: finish Proto v4 and get it in trunk. Improve the compile
times of Phoenix/Proto and get it in the review queue. Then get Bind
working with the Phoenix/Proto placeholders.

<snip>

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com

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