function<void()> task = bind( &File::HashFile, static_cast<HashFn>(bind(&Comparator::CompareData, ref(compare), _1, _2, _3, false)), ref(*pFile1) );
function<void()> task = [&](){ File::HashFile( bind(&Comparator::CompareData, ref(compare), _1, _2, _3, false), *pFile1 ); };
function<void()> task = [&](){ File::HashFile([&](const void *pv, size_t cb, const char *szDesc) { compare.CompareData(pv, cb, szDesc, false); }, *pFile1 ); };
(Random comment: The 170 lines of incomprehensible errors you get if you forget the static_cast<HashFn> on the first line is completely obnoxious. [HashFn is a typedef for function<void(const void *, size_t, const char *)>])
The last one is the best
Lambdas supersede bind() 99% of the time - they are easier to read, easier to write, more efficient, and don't explode horribly. The remaining 1% of cases are better handled by handwritten functors (e.g. with templated function call operators).
This is especially true now that 16.1/VC11's lambdas v1.1 handle nested lambdas just fine. (In contrast, nested bind() is a bug farm, which has been tormenting me for years.)
I wish it was true…
Lambdas aren’t polymorphic (and even when I write my own ad hoc function objects I prefer to make them stateless and just use bind for state)
You do not have to specify the argument(s) type(s)
IMHO, for simple bindings, bind is easier to read
Bind has been around for so many years that, at least to me, it just come natural.
I completely agree about nested binds: understanding them is mindbending.