On 03/02/2011 16:45, Thomas Heller wrote:
Now, let's consider another case, I want to do a.foo(b.bar()) + c.baz, but with a, b, and c taken from the scope, and I don't want to have to specify the types of a, b, and c. I can't do that in Phoenix without defining the foo, bar and baz functions at namespace scope, since they must have a template operator(), which is only allowed at that level. I can, however, do that with no problem with Boost.Local.
Well, you have seen nothing yet
http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/ht...
Mathias Gaunard <mathias.gaunard <at> ens-lyon.org> writes: phoenix/inside/extending_actors.html
A boilerplate macro for that would be a very welcome contribution...
All of this still needs to happen at namespace scope.
Sure it would. The point of this exercise was to adapt some "old style" C++ class to be used in a phoenix expression. Much in the fashion of BOOST_FUSION_ADAPT_STRUCT. Since you complained about using member functions in a phoenix expression is a pain ...
The problem with declaring those things at namespace scope is that they necessarily become far away from the lambda function you want to write.
Arguing like that disqualifies every library, since the defintion of the functions you want to use is _very_ far away... I don't see a point in that argument.