2013/10/23 Edward Diener

On 10/22/2013 4:16 PM, Piotr Wygocki wrote:

...

Hi, I've developed a small set of functors and functor adaptors. Although this code is very simple it might be very useful for some subset of the community.

Do you think it might become a part of the boost library? If not I'm still very interested in any feedback. I think it's not big enough to be a separate library. To my knowledge of boost it fits in the utility lib.

The code can be found here:

https://github.com/wygos/**functors https://github.com/wygos/functors

List of utilities:

SkipFunctor takes any number of arguments; does completely nothing

ReturnSomethingFunctor takes any number of arguments; returns t;

IdentityFunctor takes one parameter and returns it.

ReturnFalseFunctor takes any number of arguments; returns false;

ReturnTrueFunctor takes any number of arguments; returns true;

ReturnZeroFunctor takes any number of arguments; returns 0;

AssertFunctor takes any number of arguments; asserts;

ArrayToFunctor<Array> Stores an object which provides operator[]. Provides operator()().

A set of non-template comparison functors (only operator() is templated): * Greater * Less * GreaterEqual * LessEqual * EqualTo * NotEqualTo

FunctorToComparator This comparator takes a functor "f" and a comparator "c". For elements (x,y) it returns c(f(x), f(y)) c is Less by default

FunctorToOutputIterator<**Functor> The output iterator stores a functor and each time the operator= is called the given functor is called

Logical operators as functors: * Not * Or * And * Xor

LiftBinaryOperatorFunctor<**Operator, FunctorLeft, FunctorRight> Functor stores a binary operator "o" and two functors "f" and "g". For given arguments args returns o(f(args), g(args)).

Boolean functor adapters. Each of them stores a boolean functor and performs an appropriate logical operation in the operator().

* NotFunctor<Functor> * OrFunctor * AndFunctor * XorFunctor

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.

Logical Xor ?

New and useful functors are always welcome but please look at Phoenix first. If you feel you still have new functors maybe you can talk to the Phoenix developers to see if they will fit in Phoenix, or submit your library if there is enough interest by others.

...

Regards,

Piotr

Hi Piotr,

Like Edward suggested, Boost.Phoenix is your library for these kinds of things and much more. I had some fun rewriting your examples with Boost.Phoenix, please see the attached file. I omitted two cases: SkipFunctor and AssertFunctor. I'm not sure how to do that, nor do I see a potential use case for those ;-) Regards, Kris

Hi Kris, thank for your feedback and code! Particularly thanks for boost::make_function_output_iterator, I didn't know about it! As I wrote before my main goal is many cases is standarization. I always prefer to use std::less<int> (now, my nontemplate Less) than writing even a tiny lambda. There is another think I noticed. The compile time of your example is 6,5 times bigger than the compile time of the original example (clang 3.3, 4,5 secondsto 0.7 second). Regards, Piotr On 23 October 2013 12:33, Krzysztof Czainski <1czajnik@gmail.com> wrote:

2013/10/23 Edward Diener

...

On 10/22/2013 4:16 PM, Piotr Wygocki wrote:

...

Hi, I've developed a small set of functors and functor adaptors. Although this code is very simple it might be very useful for some subset of the community.

Do you think it might become a part of the boost library? If not I'm still very interested in any feedback. I think it's not big enough to be a separate library. To my knowledge of boost it fits in the utility lib.

The code can be found here:

https://github.com/wygos/**functors https://github.com/wygos/functors

List of utilities:

SkipFunctor takes any number of arguments; does completely nothing

ReturnSomethingFunctor takes any number of arguments; returns t;

IdentityFunctor takes one parameter and returns it.

ReturnFalseFunctor takes any number of arguments; returns false;

ReturnTrueFunctor takes any number of arguments; returns true;

ReturnZeroFunctor takes any number of arguments; returns 0;

AssertFunctor takes any number of arguments; asserts;

ArrayToFunctor<Array> Stores an object which provides operator[]. Provides operator()().

A set of non-template comparison functors (only operator() is templated): * Greater * Less * GreaterEqual * LessEqual * EqualTo * NotEqualTo

FunctorToComparator This comparator takes a functor "f" and a comparator "c". For elements (x,y) it returns c(f(x), f(y)) c is Less by default

FunctorToOutputIterator<**Functor> The output iterator stores a functor and each time the operator= is called the given functor is called

Logical operators as functors: * Not * Or * And * Xor

LiftBinaryOperatorFunctor<**Operator, FunctorLeft, FunctorRight> Functor stores a binary operator "o" and two functors "f" and "g". For given arguments args returns o(f(args), g(args)).

Boolean functor adapters. Each of them stores a boolean functor and performs an appropriate logical operation in the operator().

* NotFunctor<Functor> * OrFunctor * AndFunctor * XorFunctor

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.

Logical Xor ?

New and useful functors are always welcome but please look at Phoenix first. If you feel you still have new functors maybe you can talk to the Phoenix developers to see if they will fit in Phoenix, or submit your library if there is enough interest by others.

...

Regards,

Piotr

Hi Piotr,

Like Edward suggested, Boost.Phoenix is your library for these kinds of things and much more.

I had some fun rewriting your examples with Boost.Phoenix, please see the attached file.

I omitted two cases: SkipFunctor and AssertFunctor. I'm not sure how to do that, nor do I see a potential use case for those ;-)

Regards, Kris

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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. 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_?

Vicente

2013/10/23 Piotr Wygocki

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?

Aha, so would something like removing the defaults from the class Algorithm, and providing a set of make_Algorithm functions solve your problem? HTH, Kris

I've done some research and found nontemplate comparison structs (less, greater...) here: ./boost/log/utility/functional/logical.hpp Sorry for confusion. Should we move it to ./boost/utility ? Regards, Piotr On 23 October 2013 15:10, Piotr Wygocki wrote:

Sure, but

1) Not everybody can construct the class using make_Algorithm. (decltype(make_Algorithm()) looks weird). 2) You need many overloads of make_Algorithm function (the number of overloads equals number of arguments + 1). In my solution you need only one overload.

Regards,

Piotr

On 23 October 2013 15:01, Krzysztof Czainski <1czajnik@gmail.com> wrote:

...

2013/10/23 Piotr Wygocki

...

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?

Aha,

so would something like removing the defaults from the class Algorithm, and providing a set of make_Algorithm functions solve your problem?

HTH, Kris

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

wrote:

Le 23/10/13 14:02, Piotr Wygocki a écrit :

...

On 23 October 2013 13:21, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr

...

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/boosthttp://lists.boost.org/mailman/listinfo.cgi/boost