Why can't I have a std::set or std::unordered_set of std::functions?
Is there any way to get it to work anyway?
Why can't I have a std::set or std::unordered_set of std::functions?
Is there any way to get it to work anyway?
On
Well, you can only check function-pointers for (in-)equality, not order. And whether two functions with the same behavior must compare differently is not quite as cut-and-dry as you might perhaps hope for.
Next, you might not only store function-pointers, but also other callables. There is no guarantee any random user-defined class has a strict weak ordering. As an example, lambdas don't.
And finally, how would you order callables of different types?
You can make the same Argument for hashing (needed for unordered containers) as for ordering (needed for ordered containers). Even the equality-comparison needed for unordered containers might not exist.
On
There is no meaningful equality operation for the general function, held by a std::function.
std::function can hold a bind of some function/method to some parameters. What is the "entry point address" of that? Ans: Some function/method in the "bind" package. And does then that "entry point address" uniquely identify that function? Ans: No.Your particular use case (for sticking std::function in a set) may not be impacted by the above issues. In that case simply wrap the std::function instance in a small struct of your own (either via direct containment or via indirection) (forwarding calls to the contained function object) and put those things in your set.
On
You can very well create an std::set of functions. The problem is that sets require an absolute order to exist between the values of its elements. This order is defined by a comparator that is then used to sort the elements of a set, to check if an element already exists, and to find a specific element back.
Unfortunately, there doesn't exist an order between functions. Suppose, that you have two functions f1() and f2(), what would be the meaning of f1 < f2 ?
Also equality is not really defined. For example, if you have
int fun1(int) { return 1; }
int fun2(int) { return 1; }
function<int(int)> f1=fun1, f2=fun2;
Should f1 and f2 be the same value if you'd insert them in a set (because it's always the same result), or is it something different (because it's different functions even though they have the same body) ?
Of course, you could trick the compiler in letting it believe that you have defined an order:
struct Comp {
using T = function<int(int)>;
bool operator()(const T &lhs, const T &rhs) const
{
return &lhs < &rhs;
}
};
set <function<int(int)>,Comp> s;
You could then insert functions in the set. But this will not work very well, because you take the address of the element, and if the same elements are swapped, the order is different.
I think that the best way to proceed, would be to use a wrapper with a member string that defines an id and use this id to sort the elements in the set (or to do the hashing in case of an unordered_set)
std::setrelies on a comparator, which is used to determine if one element is less than the other.It uses
std::lessby default, andstd::lessdoesn't work withstd::functions.(Because there is no way to properly compare
std::functions.)Similarly,
std::unordered_setrelies onstd::hashandstd::equal_to(or custom replacements for them), which also don't operate onstd::functions.You can write a wrapper around (or a replacement for)
std::functionthat works withstd::less,std::equal_toand/orstd::hash.Via power of type erasure, you can forward
std::less/std::equal_to/std::hashto objects stored in your wrapper.Here's a proof-of-concept for such a wrapper.
Notes:
You can specify whether or not you want the
class FancyFunctionto work withstd::less,std::equal_toandstd::hashseparetely, by adjusting a template argument.If some of those is enabled, you'll be able to apply them to
FancyFunction.Naturally, you'll be able to construct
FancyFunctionfrom a type only if they can be applied to that type.There is a static assertion that fires when a type fails to provide
std::hashif it's needed.It seems to be impossible to SFINAE on availability of
std::lessandstd::equal_to, so I couldn't make similar assertions for those.In theory, you could support types that don't work with
std::less,std::equal_toand/orstd::hashby always considering all instances of one type equivalent, and usingtypeid(T).hash_code()as a hash.I'm not sure if that behavior is desirable or not, implementing it is left as an exercise to the reader.
(Lack of SFINAE for
std::lessandstd::equal_towill make it harder to implement properly.)Specifying custom replacements for
std::less,std::equal_toandstd::hashis not supported, implementing that is also left as an exercise to the reader.(This means that this implementation can only be used to put lambdas into a regular
std::set, notstd::unordered_set.)When applied to
FancyFunction,std::lessandstd::equal_towill first compare types of stored functors.If types are identical, they'll resort to calling
std::less/std::equal_toon underlying instances.(Thus, for two arbitrary different functor types,
std::lesswill always consider instances of one of them less than instances of the other one. The order is not stable between program invocations.)Example usage:
Implementation: