Boost logo

Boost :

Subject: Re: [boost] phoenix::bind
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-10-02 06:12:23


On Thu, Oct 2, 2008 at 4:53 AM, Joel de Guzman
<joel_at_[hidden]> wrote:
> Giovanni Piero Deretta wrote:
>>
>> On Wed, Oct 1, 2008 at 5:32 AM, Joel de Guzman
>
>>> "Primary motivation for including protect into the library,
>>> was to allow nested STL algorithm invocations (the section
>>> called "Nesting STL algorithm invocations"
>>> [http://tinyurl.com/5xm6rt])."
>>>
>>
>> I never got that detail. How is protect better in that case than using
>> unlambda? Why would I want to mask a lambda just for one evaluation
>> round and not forever?
>
> Because you can't use unlambda there. See my other post.
>
>>> Phoenix had lazy functions since its inception. The general problem
>>> was how to implement a higher-order-function that accepts higher-
>>> order-function. Like say:
>>>
>>> phx::for_each(_1, std::cout << _1 << std::endl)
>>>
>>> substituting the left _1 for the container. The right _1 substitutes
>>> the container's element which happens when for_each invokes the
>>> input function for each element: f(element).
>>>
>>> But that can't happen because all _1 will be substituted eagerly.
>>> hence, it was necessary to brace the higher-order-function argument:
>>>
>>> phx::for_each(_1, lambda[std::cout << _1 << std::endl])
>>>
>>
>> Ok, I do exactly the same with a modified boost.lambda, except that
>> the 'lambda[]' syntax has 'unlambda' semantics, not 'protect'
>
> No it does not.

Oh yes, I'm sure it does, otherwise my code wouldn't work :)

Long answer in the other post.

-- 
gpd

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk