From: Eric Niebler (eric_at_[hidden])
Date: 2008-07-01 11:39:44
Giovanni Piero Deretta wrote:
> Yes please. The only thing that prevents me to use Phoenix every day
> is the fact that it is not an official boost library. If it were to
> become 'first class' personally I would be glad to ditch lambda.
> Still I do not think that having both libraries for only one release
> is enough, probably boost should carry both of them for a while (3, 4
> releases), with explicit deprecation makers. Boost.lambda is a big and
> complex library, and it might take time to do a good conversion.
> Now, some questions:
> - Does Phoenix 3.0 (or 2.0) compile faster or slower than boost.lambda
> (on common expressions at least). Seen the care that Eric took to
> tweak Proto, I would say faster.
At the moment, Phoenix 3 (with Proto) compiles slower than Phoenix 2. I
haven't benchmarked either against Lambda. Both Phoenix 2 and Lambda are
surprisingly lightweight, so porting them to Proto without incurring a
compile-time perf hit is a challenge. But I've only just begun
optimizing it for compile times.
> - Last time I checked Phoenix only had a monomoprhic bind. If you have
> polymorphic functions you have to convert them to lazy functions. I
> think that adding a polymorphic bind (like lambda shouldn't be hard).
> - Would it be possible to tell Phoenix the default capture mode, like
> in C++0x lambdas? By default lambda ( or any implicit lambda
> expression) would capture by value, but something like lambda_r[ ] (_r
> for reference) would get rid of many ref/cref at least for upward
> funargs. I do not know how easy is to do it, but I guess that proto
> make it possible (in fact I think that the reverse would be easier:
> capture by reference by default and then a top level lambdac would
> traverse the expression and convert any implicitly captured reference
> to a copy).
An interesting suggestion. Joel?
> - What are exactly the quirks that makes it hard to have full backward
> compatibility? Well except for 'sig' of course.
Wish I had written them all down. One that sticks in my mind is whether
variables are captured by value or by reference. With Phoenix, it's very
consistent ... all variables are captured by value, always. Lambda tries
to be a bit more helpful, and it makes the rules more confusing, IMO.
Most of the time, variables are captured by value, but a variable on the
left of an assignment is captured by reference. This includes all the
assignment operators, like plus-assign. So the following is a valid
int i = 0;
i += _1;
But in Phoenix, it would have to be:
int i = 0;
ref(i) += _1;
-- Eric Niebler BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk