CppCon 2015: Stephan T. Lavavej “functional: What's New, And Proper Usage"
Why Stack Overflow recommends it
Stack Overflow users link it as the authoritative reason to avoid std::bind in favor of lambdas, and for details on std::function behavior and deprecated helpers like binary_function.
Recommended by 10 people across 13 different months, 2015 to 2023.
What it is
Stephan T. Lavavej of Microsoft's C++ Standard Library team presents CppCon 2015 talk on <functional>: what changed in C++11, 14 and 17, and how to use it properly. It covers std::function internals such as the small functor optimization, bind(), mem_fn(), invoke(), and why lambdas are usually the better tool.
What people said
Strong rec Nir Friedman · 2016-11 · Stack Overflow · on “Error using std::bind and std::function in C++”
@Nicholas bind is not really recommended. It's a very complicated and not very intuitive beast that was invented in the days before lambdas. If you want to dig into this topic I highly recommend this talk: [this video]
Recommends user5443145 · 2015-10 · Stack Overflow · on “replacement for std::binary_function”
First, my advice is to watch CppCon 2015: Stephan T. Lavavej "functional: What's New, And Proper Usage" [this video] . std::binary_function is mentioned on slide 36, at around 36 mins in the video. You can find the slides at github.com/CppCon/CppCon2015). It doesn't go into detail why you shouldn't use std::binary_function , but if you're using something that's been deprecated since C++11, then you would probably benefit from watching it. If you want the actual rationale for not using it, try n4190: unary_function/binary_function were useful helpers when C++98-era adaptors needed argument_type/etc. typedefs. Such typedefs are unnecessary given C++11's perfect forwarding, decltype, and so forth. (
Recommends Brad · 2015-11 · Stack Overflow · on “Reducing std::bind template code bloat?”
I dug into this a bit more and watched @John [LINK] 's video on std::function . In the video [this video] , STL recommends using lambdas over std::bind for a few reasons. I tried converting the code to use a Lambda, which is exactly what @Igor Tandetnik [LINK] recommended above. It is significantly better. mCallbackObj(std::bind(&MyClass::MyFunc, this, _1)) Takes an additional 2,888 bytes of codespace. Instead using mCallbackObj([this](void *info){MyFunc(info);}) Only takes an additional 812 bytes! This is significantly better, and good enough for my use-case. For C++ programmers unfamiliar with the syntax of std::bind, the lambda solution is also easier to read. Update - After bumping to GCC 6.0
Recommends Ap31 · 2016-09 · Stack Overflow · on “Why do shared_ptr deleters have to be CopyConstructible?”
The difference between deleters in std::shared_ptr and std::unique_ptr is that shared_ptr deleter is type-erased, while in unique_ptr deleter type is part of the template. Here is Stephan T. Lavavej explaining [this video] how type erasure leads to CopyConstructible requirement in std::function . As for the reason behind this difference in pointer types, it has been addressed on SO several times, e.g. here [LINK] . A quote of what S.T.L. said: Very surprising "gotcha" I would say is that the std::function requires CopyConstructible function objects, and this is kind of unusual in the STL. Usually the STL is lazy in the sense that it doesn't need things up front: if I have something like a std::li
Recommends Vittorio Romeo · 2016-11 · Stack Overflow · on “bind return value and variadic templates”
Why does the task need to know about the function arguments? The task should be a void() type-erased callable object. using Task = std::function<void()>; Task task([]{ prtinhi(5); }); ThreadPool pool; pool.schedule(task); // ... // `prtinhi(5)` will be eventually called. If you need to get the return value, you want std::future [LINK] . ThreadPool could be implemented as follows: struct ThreadPool { some_lockfree_queue<Task> _queue; std::vector<std::thread> _workers; void initialize() { for(int i = 0; i < num_threads; ++i) { _workers.emplace_back([this] { Task t = _queue.try_dequeue(); t(); }); } } }; std::bind is bad (watch this talk by STL [this video] for more info) . You should use lambdas [L
Recommends Vittorio Romeo · 2016-12 · Stack Overflow · on “Wrapper to std::async() not working”
You need to change your runAsyncTerminateOnException call as follows: std::future<void> future2 = runAsyncTerminateOnException(&Foo::print<const int&>, &foo, 2); This is due to an unfortunate interaction between std::bind, variadic templates and perfect forwarding [LINK] . I suggest you to use lambdas instead, which are almost always superior to std::bind . (For more information, see this talk [this video] from STL.) template<class Fn> inline auto runAsyncTerminateOnException(Fn&& fn) { return std::async(std::launch::async, [=]() -> decltype(fn()) { try { return fn(); } catch (...) { std::cout << "Terminate Called!" << std::endl; std::terminate(); } }); } (Note that I'm copying fn into the lambda
Recommends Vittorio Romeo · 2017-01 · Stack Overflow · on “How to boost::bind a template member function which takes a universal reference as a parameter”
I would suggest against using boost::bind , as lambda expressions [LINK] can be used to cleanly bind arguments (avoiding many pitfalls of bind explained in this talk by STL [this video] ) . I'm assuming that you want to: Capture a by move if an rvalue-reference is passed to getInt . Capture a by reference if an lvalue-reference is passed to getInt . I'm also assuming that: A is not int in your real code, otherwise perfect-forwarding would not make sense. You want to avoid unnecessary copies of a or that A could be a move-only type. You only have access to C++11 (and not to newer standards) . If you need to "perfectly-capture" a (i.e. capture-by-move if A is an rvalue-reference, capture-by-referen
Recommends narfster · 2017-07 · Stack Overflow · on “C++0x lambda wrappers vs. bind for passing member functions”
Some updated advise i found useful: IStephan T. Lavavej advise on not binding "Avoid using bind(), use lambdas". [this video] is pretty good. example for a wrapping of a member function in a lambda function and sending to a 2nd matrix object's member function to apply with that function. //some member function that does cool math stuff float a_class::math_func(float x) { return 1.0f; } // another member function void a_class::some_func2() { //create spot matrix of window size util_mat::mat<float> spot(window_size_, window_size_); auto f_callback = [this](float n) { return math_func(n); }; //apply math callback function on spot matrix and get new noise matrix. util_mat::mat<float> noise_mat = spot
Recommends Vittorio Romeo · 2017-10 · Stack Overflow · on “Is there a mutable version of std::bind?”
However at least to me personally bind looks much cleaner and simpler in this case. Do not use std::bind in C++11. Use lambdas instead. std::bind has several issues excellently explained in this talk by Stephan T. Lavavej “functional: What's New, And Proper Usage" [this video] . [LINK] It might look simpler and cleaner in this case, but it's not recommended. Writing... [&ptr]{ foo(std::move(ptr)); }(); ...is the proper way of solving this problem.
Recommends StoryTeller - Unslander Monica · 2017-11 · Stack Overflow · on “usage of this pointer in std::bind”
@Jaa-c - It'd be far more educational to watch this lecture [this video] . If you are unfamiliar with the presenter, it's Stephan T. Lavavej, the maintainer of Micrsoft's standard library implementation.