On Sat, Feb 5, 2011 at 3:35 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
On 2/6/11 1:03 AM, Lorenzo Caminiti wrote:
Plus, how would local variables and local classes look in Boost.Pheenix? In Boost.Local it's like in normal C++:
BOOST_LOCAL_FUNCTION( (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) ) ) { const std::string msg = "Summed: "; // A const local var. struct text { std::string say; } // A local struct. test t; // A local var. t.say = msg;
sum += factor * num; std::clog<< t.say<< sum<< std::endl; } BOOST_LOCAL_FUNCTION_END(add) add(100.0);
How would this look in Boost.Phoenix? I wish I knew Phoenix better :) so I could provide the answers myself...
Look, let us please stop this syntax nonsense. As mentioned, phoenix can have all those above (pure c++ function syntax, local classes, local variables, etc.) in the form of offline phoenix::function. Why offline? I argue, and I am sure many agree, that overly complex inlined lambdas add clutter to the enclosing function. Local function emulation is at best a poor rendition of what it should be anyway (e.g. like Pascal's local function) since it doesn't have direct access to the enclosing scope and thus have to resort to argument binding and some such and add *A LOT* of clutter.
At any rate, I repeatedly say: I am not against Boost.Local. As I said, in as much as we have BOOST_FOREACH and std::bind, I see no reason why we can't have Boost.Local.
Agreed. I think we discussed the syntax stuff enough. (Sorry but I wrote the email above before reading the related discussions in Greg's "Case study: Boost.Local versus Boost.Phoenix" so my comments were out of sync with the status of the discussion :) .) -- Lorenzo