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.
I agree.
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 lambda expression: 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