Why there is no implicit conversions to pointers of member functions-CodePudding

When used std::bind, I found & is necessary to get the address of member functions, while isn't necessary for regular functions, for example:

class Obj{
public:
    void member_func(int val);
};

void func(int val);

int main(){
    Obj obj;
    auto mf1 = std::bind(&Obj::member_func, &obj, 1); // ok
    auto mf2 = std::bind(Obj::member_func, &obj, 1); // error
    
    auto f1 = std::bind(&func, 1); // ok
    auto f2 = std::bind(func, 1); // ok
}

And after STFW(Search The Friendly Web :) ), I found this in cpp reference

An lvalue of function type T can be implicitly converted to a prvalue pointer to that function. This does not apply to non-static member functions because lvalues that refer to non-static member functions do not exist.

Which explains why & is necessary for member functions, but I still don't fully understand why there is no implicit conversions to pointers of member functions?

In particular, what does "lvalues that refer to non-static member functions do not exist" mean?

And "lvalue of function type" also confuses me, does that mean the function designator func is an lvalue?

First time to ask question, hope I clearly explained my question.

CodePudding user response：

I still don't fully understand why there is no implicit conversions to pointers of member functions.

It's to stop you making mistakes like this:

if (MyClass::MyFunc) ...                    // oops! would always be true, if legal

when you meant to type:

if (MyClass::MyFunc ()) ...
//                  ^^

And that's a Good Thing (tm).

But that begs the question, why don't things work the same way for regular functions? After all, it's perfectly legal (but, as in the example above, totally meaningless) to write:

if (MyNonMemberFunc) ...                    // oops! always true, rats!

And this is a throwback to C, where function names decay to pointers when you leave the brackets off. That has value, but overall I think most people would prefer correctness to having to add a leading & when that is the intention.

So it's a bit unfortunate that we have different rules for member and non-member functions, but the standards committee obviously wanted to fix this particular booby trap for member functions but couldn't for non-member functions, in order to maintain backwards compatibility. And to be fair, most modern compilers do warn you if you write if (MyNonMemberFunc) so we're not in such a bad place with this, all things considered.

CodePudding user response：

why there is no implicit conversions to pointers of member functions?

Pointer to non-static member functions are not actually pointers. This can be seen from the following statement in the standard:

From dcl.mptr#3's note:

[ Note: See also [expr.unary] and [expr.mptr.oper]. The type “pointer to member” is distinct from the type “pointer”, that is, a pointer to member is declared only by the pointer to member declarator syntax, and never by the pointer declarator syntax. There is no “reference-to-member” type in C . — end note ]

And from basic.compound#3:

...Except for pointers to static members, text referring to “pointers” does not apply to pointers to members...

(emphasis mine)

The combination of the above two quoted statements explain why we need to use & for pointer to member function as explained below.

Note the highlight part("distinct type") in the above quoted statement. Since a pointer to member is a distinct type and text referring to pointers does not apply to pointers to members this means that they should be treated differently. Which is why we need to explicitly add the & for them to emphasize on the fact that they are distinct from the type pointer.

Now coming to your second question:

what does "lvalues that refer to non-static member functions do not exist" mean?

The standard specifically says(in the same note quoted above) that:

There is no “reference-to-member” type in C .