On 02/01/2011 11:00 PM, Thomas Heller wrote:
I would be interested in what limitations you ran into using Boost.Lambda and if you are aware of the recent efforts that were put into Boost.Phoenix?
I ran into two problems specifically. The first was that my functions had just over three arguments. The second was that I wanted my function to have a nested function inside of it --- that is, another closure that it could pass to an STL algorithm such as for_each --- and although I saw that this was doable in principle I couldn't figure out how to make it work even though I could have sworn I was following the documentation, and the error messages gave me no insight at all into what I was doing wrong. Also, one of the things that I really liked about Boost.Local was that I didn't have to figure out how to cram what I wanted into special syntax; after writing the boiler-plate to create the closure function, I could program in normal C++ syntax, which made life easy. I hadn't looked at the latest version of Phoenix until just now, so I didn't realize that so much had changed --- thank you very much for directing my attention towards it! It looks like it might actually fit the bill for most of my uses, so when I get a chance I will experiment with using it to replace Boost.Local in my code. There are some cases where the function body is sufficiently non-trivial that translating everything into the special syntax of Phoenix might be a pain, but I could very well be wrong. I'll let you know what I think about how how well it solves the problem I faced versus Boost.Local after I've tried it out. Cheers, Greg