How to work around the fact that std::function has no operator==?

Question

Problem: The following code would be very expressive and concise, if not necessarily fast, were it not for the fact that it does not compile.

It does not compile because you cannot compare std::function instances with operator==(). And std::find() tries to do exactly that.

Of course, I could go for an entirely different kind of implementation, but stubborn as I am and fond as I am with the code below, I am looking for something "closest as possible" which works.

Who can provide me a pretty rewrite of the code below which does the same thing?

#include <functional>
#include <vector>

typedef std::function<bool(int)> Tester_t;
typedef std::vector<Tester_t> TesterSet_t;

bool Test(TesterSet_t &candidates, int foo)
{
    TesterSet_t dropouts;
    for( auto& tester : candidates )
    {
        if(!tester(foo))    
        {
            droputs.push_back(tester);
        }
    }

    while(!dropouts.empty())
    {
        // The following line is not compiling because std::function has no operator==()
        TesterSet_t::iterator culprit = 
            std::find( candidates.begin(), candidates.end(), dropouts.back() );
        candidates.erase(culprit);
        dropouts.pop_back();
    }
    return !candidates.empty();
}

Answer 1

As others have said, you don't need comparison of std::functions for this. Using standard C++ facilities this can be efficiently (with linear complexity) implemented in two lines:

bool Test(TesterSet_t &candidates, int foo)
{
    candidates.erase(std::remove_if(candidates.begin(), candidates.end(),
        [foo](Tester_t& f){ return !f(foo); }), candidates.end());
    return !candidates.empty();
}

Answer 2

You don't need equality here. Just erase as you go

for (auto it = candidates.begin(); it != candidates.end(); ) {
    if (! (*it)(foo) ) {
        it = candidates.erase(it);
    }
    else {
        ++it;
    }
}
return !candidates.empty();

This will be also be faster than the version in the question even if operator== was defined for std::function.

Answer 3

If you ever dont need to erase candidates you can write:

bool Test(TesterSet_t &candidates, int foo)
{
    return std::any_of(candidates.begin(), candidates.end(), [&foo](Tester_t &tester) {
        return tester(foo);
    });
}

UPDATE

Okay, you need to remove candidates

bool Test(TesterSet_t &candidates, int foo)
{
    candidates.erase(
        std::remove_if(candidates.begin(), candidates.end(), [&foo](Tester_t &tester) {
            return !tester(foo);
        }),
        candidates.end()
    );
    return !candidates.empty();
}

Answer 4

The simple answer is not to use std::function<...> in this case but rather something like std::function<...> which does define an equality operators. The approach to define an equality operator for function<...> is to detect upon construction whether the actual function object actually contains an equality operator and, if so, make the object comparable. Otherwise, you'd either produce an error or you'd consider objects holding this particular function object type to be incomparable.

The immediate observation is, however, that most function objects are not comparable! For example, lambda functions are not comparable and std::bind() and std::mem_fn() also don't yield comparable function objects. Again, there can be a custom implementation for std::bind() and std::mem_fn(). There is no way to make lambda functions comparable unless the have an empty capture in which case they could be turned into function pointers and could be compared.

The implementation of equality-aware function objects is a bit too long to quickly type into a response. However, you can have a look at my implementation at github for equality-comparable bind() and mem_fn(). See this answer for an implementation of an equality comparable version of std::function<...>. It may be desirable to have lambda functions be comparable, too, if they have the same signature and all captured values are equality comparable.

All that said, if you can avoid the need, it is probably best avoided. However, I have come across some uses cases where a comparable std::function<...> would be rather handy despite its restrictions (i.e., not all function objects will be covered).