From: David Abrahams (dave_at_[hidden])
Date: 2008-07-01 11:27:15
Eric Niebler wrote:
> David Abrahams wrote:
>>>> Here are the parts and topics that I see as being in the category:
>> * 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:
> 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.)
The analogy doesn't seem quite right, but OK
> forwards reference-wrapped arguments to the monomorphic implementation
> as lvalues, and all others as rvalues.
Very cool. I don't suppose it's possible to forward lvalues and const
rvalues as lvalues, and mutable rvalues as rvalues? I haven't thought
of a way, but that would be as close to "perfect" as we might expect to
get in C++0x and it would be close enough for me :-)
> 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.
Yep. It's a big coordination job.
>> * 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.
Problem: it's not publicly available in Boost (yet)/
>> * 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.).
That's OK too, although Joel still seems to be intent on an eventual merger.
> placeholders should be Proto terminals shared across Phoenix, Bind,
> Xpressive, Spirit and any other library that needs numbered
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk