- Wszelkie boost::bind-y, std::bind-y i prawdopodobnie lambdy używają wewnętrznie podobnego mechanizmu.
Boost::bind wykorzystuje szablony niemal w identyczny sposób do dedukcji typu argumentów, kontekstu oraz typu zwracanego
z przekazywanego wskaźnika na metodę R (T::*method)(Args...).
W uproszczeniu wygląda to tak:
template<class R, class T, class... Args>
binder<R, T, Args...> my_bind(R (T::*method)(Args...),
const T &context, const placeholder &)
{
return binder<R, T, Args...>(method, context);
}
gdzie binder jest z kolei obiektem funkcyjnym zwracanym przez bind-a i przedstawia się
mniej więcej tak:
template<class R, class T, class... Args>
class binder
{
typedef R (T::*Method)(Args...);
public:
binder(Method method, T context)
: method_(method),
context_(context)
{
}
R operator ()(Args... args)
{
return (context_.*method_)(args...);
}
private:
Method method_;
T context_;
};
- Różnego rodzaje message/event dispatchery, które z natury pracują na zbiorze zarejestrowanych handler-ów
(a więc znowu obiekty std::function) i muszą jakoś dopasować jednego z nich do aktualngo msg-a/eventa/grupy argumentów.
Z bardziej hardkorowych to np. ten tutaj http://stackoverflow.com/questions/25714390/is-it-possible-to-do-this-lambda-event-manager-in-c
w function_traits dokonuje dedukcji wskaźnik na metodę R(C::*)(Args...) -> std::tuple<Args...>