Deficiency in std::mem_fn compared to hand-rolled functor

Question

I have come across a use case where std::mem_fn cannot do something that a hand-rolled wrapper function can. It comes up when the wrapper function is used on something that's not of the method's class, but a type implicitly convertible to it:

#include <functional>

struct A
{
};

struct B
{
    B(A);  // implicit conversion from A to B
    void foo() const;
};


auto foo1 = std::mem_fn(&B::foo);     // std::mem_fn

void foo2(const B& b) { b.foo(); }    // hand-rolled wrapper

int main()
{
    A a;
    foo1(a);  // doesn't work
    foo2(a);  // works fine
}

The compiler error for the call to foo1 is the following (with GCC 4.8):

In file included from test.cpp:1:0:
functional: In instantiation of '_Res std::_Mem_fn<_Res (_Class::*)(_ArgTypes ...)const>::_M_call(_Tp&, const volatile void*, _ArgTypes ...) const [with _Tp = A; _Res = void; _Class = B; _ArgTypes = {}]':
functional:608:42:   required from '_Res std::_Mem_fn<_Res (_Class::*)(_ArgTypes ...)const>::operator()(_Tp&, _ArgTypes ...) const [with _Tp = A; _Res = void; _Class = B; _ArgTypes = {}]'
test.cpp:21:11:   required from here
functional:586:13: error: no match for 'operator*' (operand type is 'A')
  { return ((*__ptr).*__pmf)(std::forward<_ArgTypes>(__args)...); }
             ^

Would it have been possible to implement std::mem_fn in such a way that this use case works just like it does with the hand-rolled wrapper?

Answer 1

It would be possible, yes, but it's not how the C++ standard specifies mem_fn.

The standard says that foo1(a) calls INVOKE(&B::foo, a) where that is defined in [func.require] as:

Define INVOKE (f, t1, t2, ..., tN) as follows:
— (t1.*f)(t2, ..., tN) when f is a pointer to a member function of a class T and t1 is an object of type T or a reference to an object of type T or a reference to an object of a type derived from T;
— ((*t1).*f)(t2, ..., tN) when f is a pointer to a member function of a class T and t1 is not one of the types described in the previous item;
— ...

Your case fails to meet the conditions of the first bullet, because a is not an object of class B, nor a reference to a B or a class derived from B, so the second bullet applies and so it's equivalent to ((*a).*f)() which isn't valid.

It's defined this way to allow smart pointers to be used, e.g.

auto foo1 = std::mem_fn(B::foo);
auto p = std::make_shared<B>();
foo1(p);

The definition of INVOKE (which is also used by bind, function, async and other parts of the library that create call wrappers) means that when invoking a wrapped pointer-to-member, if the first argument t1 isn't a T then it is assumed to be some kind of pointer and gets dereferenced. This means it works with std::shared_ptr and std::unique_ptr but also with types that std::mem_fn knows nothing about, such as boost::shared_ptr and MyVeryOwnSmartPtr.

To make your code work it would be possible to add extra cases to handle when t1 is not a T or a type derived from T, but is_convertible<T>::value is true, and to invoke T(t1).*f)(), but that would complicate the specification and might have undesirable consequences in some cases.

Your "wrapper" will force the implicit conversion of its argument, but it can't handle smart pointers or rvalues of type B, which are both supported by mem_fn. If you have a specific case where you want to convert A objects to B to call the function, then just do that, the generic mem_fn template isn't suitable, but it is more flexible and generic and works in plenty of other situations.

(N.B. the definition of INVOKE is actually defective because it dereferences std::reference_wrapper objects in the same way as it dereferences your a argument. I've proposed a fix at http://cplusplus.github.com/LWG/lwg-active.html#2219, but that doesn't affect your example.)