Boost logo

Boost :

Subject: Re: [boost] [functors] proposal
From: Piotr Wygocki (vwygos_at_[hidden])
Date: 2013-10-24 14:16:21


Hi Vincente, thank you for your response.

IMO these structs do not belong to phoenix, because they behave in a
different way (see me struct Algorithm example).
In fact in many use cases they are redundant with phoenix structs.
Also I see no big interest in these functionalities.
I conclude these scenarios are not so common as I thought and I should keep
my toys for myself :)

Kind Regards,

Piotr

On 24 October 2013 19:40, Vicente J. Botet Escriba <vicente.botet_at_[hidden]
> wrote:

> Le 23/10/13 14:02, Piotr Wygocki a écrit :
>
>> On 23 October 2013 13:21, Vicente J. Botet Escriba <
>> vicente.botet_at_[hidden]
>>
>>> wrote:
>>> Le 23/10/13 13:10, Piotr Wygocki a écrit :
>>>
>>> Than you for your feedback!
>>>
>>>>
>>>>
>>>> Are you aware of Boost.Phoenix ( or its predecessor Boost.Lambda ) ?
>>>> Also
>>>>
>>>>> some of the functors appear to duplicate functors in the C++ standard
>>>>> library in functional.
>>>>>
>>>>> 1) This is good point, this functors are for this kind of people who
>>>> like
>>>> lambdas.
>>>>
>>>> Many of proposed functors are equivalent to very simple lambdas.
>>>> For example:
>>>> ArrayToFunction can be replaced in most cases replaced with
>>>>
>>>> auto arrayToFunction = [&](int i){ return v[i];};
>>>>
>>>> or
>>>>
>>>> auto arrayToFunction = phoenix::ref(v)[_1];
>>>>
>>>> In this case my proposal is to standarize this kind of popular
>>>> usage:
>>>> auto arrayToFunction = make_ArrayToFunctor(v);
>>>>
>>>> Popularity is subjective.
>>>
>>
>> Sure. I chose functors which are popular in MY opinion.
>> I think you agree that "Less" is popular.
>>
>>
>> 2) There is another use case for people who like passing functors and
>>> need
>>>
>>>> default arguments.
>>>>
>>>> For example my SkipFunctor does exactly the same job as
>>>> phoenix::nothing.
>>>> For example my RetrunFalseFunctor does exactly the same job as
>>>> phoenix::val(true).
>>>>
>>>> Look at this use case:
>>>>
>>>> template <typename SomeAction = SkipFunctor, typename
>>>> StopCondidtion =
>>>> ReturnFalseFunctor>
>>>> struct Algorithm {
>>>>
>>>> };
>>>>
>>>> AFAIK it cannot be replaced with phoenix construction because we do
>>>> not
>>>> have the type of the nothing functor.
>>>> Particularly, note that decltype(phoenix::nothing) is not going to
>>>> work.
>>>>
>>>> This is tiny difference but this play a big role in a code I write.
>>>>
>>>> What about adding phoenix::true_/phoenix::false_****?
>>>>
>>> I don't get it. Could you be more specific?
>>
>> I'd like to reestablish my use case. My previous post was messy (sorry!).
>> We've got a class which can be modified by some functors.
>> This functors have default values:
>>
>> template <typename SomeAction = SkipFunctor, typename StopCondidtion
>> =ReturnFalseFunctor>
>> struct Algorithm {
>> Algorithm(SomeAction action = SomeAction(), StopCondidtion =
>> StopCondition());
>>
>> };
>>
>> Could you solve this using constructions from phoenix?
>> The second question is of course: is this a good design?
>>
>>
>> I was just suggesting that if these functors are missing in
> Boost.Phoenix, just make a Feature request, propose a patch with the code,
> the documentation and test and I'm sure the author will accept it.
>
> I was also suggesting that the name could be true_ and false_ for instead
> of ReturnTrueFunctor and ReturnFalseFunctor
>
> Best,
>
> Vicente
>
>
> ______________________________**_________________
> Unsubscribe & other changes: http://lists.boost.org/**
> mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
>


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