I implemented a generic event emitter class which allows code to register callbacks, and emit events with arguments. I used Boost.Any type erasure to store the callbacks so they can have arbitrary parameter signatures.
It all works, but for some reason, lambdas being passed in must first be turned into std::function
objects. Why doesn't the compiler infer that the lambda is the function type? Is it because of the way I use variadic templates?
I use Clang (version string: Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
).
Code:
#include <functional>
#include <iostream>
#include <map>
#include <string>
#include <vector>
#include <boost/any.hpp>
using std::cout;
using std::endl;
using std::function;
using std::map;
using std::string;
using std::vector;
class emitter {
public:
template <typename... Args>
void on(string const& event_type, function<void (Args...)> const& f) {
_listeners[event_type].push_back(f);
}
template <typename... Args>
void emit(string const& event_type, Args... args) {
auto listeners = _listeners.find(event_type);
for (auto l : listeners->second) {
auto lf = boost::any_cast<function<void (Args...)>>(l);
lf(args...);
}
}
private:
map<string, vector<boost::any>> _listeners;
};
int main(int argc, char** argv) {
emitter e;
int capture = 6;
// Not sure why Clang (at least) can't deduce the type of the lambda. I don't
// think the explicit function<...> business should be necessary.
e.on("my event",
function<void ()>( // <--- why is this necessary?
[&] () {
cout << "my event occurred " << capture << endl;
}));
e.on("my event 2",
function<void (int)>(
[&] (int x) {
cout << "my event 2 occurred: " << x << endl;
}));
e.on("my event 3",
function<void (double)>(
[&] (double x) {
cout << "my event 3 occurred: " << x << endl;
}));
e.on("my event 4",
function<void (int, double)>(
[&] (int x, double y) {
cout << "my event 4 occurred: " << x << " " << y << endl;
}));
e.emit("my event");
e.emit("my event 2", 1);
e.emit("my event 3", 3.14159);
e.emit("my event 4", 10, 3.14159);
return EXIT_SUCCESS;
}
When
boost::any
stores a value, it uses the static type of that object to determine what type of object is being stored. You can then only cast theany
back to an object of the right type if you specify the static type of what's being stored.Each C++ lambda is associated with an implementation-defined type that's opaque to the user. Although lambdas can be called as functions, they don't directly evaluate to
std::function
s. The cast is necessary when storing the lambda in theany
to ensure that the static type of what's stored is astd::function
for when you cast back.Hope this helps!
A lambda is not a
std::function
, andstd::function
is not a lambda.A lambda is syntactic sugar to create an anonymous class that looks like this:
from this:
with the type name of the
my_lambda
actually being some unnameable type.A
std::function
is a completely different thing. It is an object that does implementoperator()
with a particular signature, and stores a smart value-semantics pointer to an abstract interface that covers copy/move/invoke operations. It has atemplate
d constructor that can take any type that supports copy/move/operator()
with a compatible signature, generates a concrete custom class that implement the abstract internal interface, and stores it in the above mentioned internal value-semantics smart pointer.It then forwards operations from itself as a value-type to the abstract internal pointer, including perfect forwarding to the invocation method.
As it happens, you can store a lambda in a
std::function
, just like you can store a function pointer.But there are a whole myriad of different
std::function
that could store a given lambda -- anything where the types are convertible to and from the arguments works, and in fact works equally well, as far as thestd::function
is concerned.Type deduction in C++ in
template
s does not work at the level "can you convert into" -- it is pattern matching, pure and simple. As the lambda is a type unrelated to anystd::function
, nostd::function
type can be deduced from it.If C++ tried to do that in the general case, it would have to invert a Turing-complete process to determine what (if any) set of types could be passed to the
template
in order to generate a conversion-compatible instance.In theory, we could add "operator deduce template arguments from" to the language, where the implementers of a given
template
can write code that takes some arbitrary type, and they attempt to tease out "from this type, whattemplate
parameters should be used for an instance". But C++ does not have this.The compiler doesn't infer anything because the compiler implements the C++ language, and the language's template argument deduction rules do not allow the deduction in the way you want.
Here's a simple example that represents your situation: