Re: [boost] [functors] proposal

24 Oct 2013


      Le 23/10/13 14:02, Piotr Wygocki a écrit :
...
On 23 October 2013 13:21, Vicente J. Botet Escriba 
...
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