2

As I understand it, methods are really just functions with an implicit extra parameter (the this pointer), and static methods are the pretty much the same as free functions.

But there seem to be some differences between methods and functions; for example, when passing a function as an argument, why does the reference operator & have to be used on methods, but not on free functions?

foobar(&MyClass::method);
goobar(freefunction);

What other subtle technical differences are there between methods and free functions?

Paul Manta
  • 30,618
  • 31
  • 128
  • 208
  • I could copy and paste the C++ FAQ but I will just link [it](http://www.parashift.com/c++-faq-lite/pointers-to-members.html) – stonemetal Dec 08 '11 at 18:30
  • possible duplicate of [Error with address of parenthesized member function](http://stackoverflow.com/questions/7134197/error-with-address-of-parenthesized-member-function) – Nawaz Dec 08 '11 at 18:38

2 Answers2

3

In:

foobar(&MyClass::method);

... & is not the "reference operator" but is the address-of operator. It takes the address of its operand.

You actually do still "have to" take the address of a free function in code such as (although implicit conversions are available):

goobar(freefunction);

There are implicit conversions available which will cause an expression such as Foo to decay in to a pointer, but I have had much difficulty in getting GCC to accept such code error- and warning-free, in cases where MSVC has no problems.

Aside from this, there are two main differences between free functions and non-static member functions:

  1. Non-static member functions operate on an instance of a class, and there is a this pointer which points to the class itself.
  2. The syntax for creating and calling through a pointer-to-free-function is different than that for a pointer-to-member-function.

In the case of the free function, the syntax is trivial(ish):

void foo();  // Function declaration
void(*f)();  // Declaration of pointer-to-function-returning-void-and-taking-no-parameters

But in the case of a pointer to a member function, the syntax is much trickier:

struct Bar
{
  void DoIt()
  {
  }
  void DoThat(int n)
  {
    n;
  }
};


void(Bar::*thatfn)(int);    // declares a pointer-to-member-function taking int returning nothing
thatfn = &Bar::DoThat;      // initializes pointer to point to DoThat(int)
(bar.*thatfn)(42);          // call the function
John Dibling
  • 99,718
  • 31
  • 186
  • 324
  • "but many compilers are lax on this." - wrong, the standard specifically states that you do not need to, as free functions decay into pointers at the drop of a hat. – Xeo Dec 08 '11 at 18:35
  • @Xeo: I've had much difficulty with implicit decomposition under Linux, whereas MSVC has no such issues. – John Dibling Dec 08 '11 at 18:40
  • @Xeo: Regardless, I've edited my words to be less offensive to people focused on the leaves of the tree. ;) – John Dibling Dec 08 '11 at 18:44
  • Well, `MSVC 1 : 0 GCC` in that case. :P – Xeo Dec 08 '11 at 18:46
1

I think it is because of (§5.3.1/3) which says,

A pointer to member is only formed when an explicit & is used and its operand is a qualified-id not enclosed in parentheses.

and then it goes on to explain this as:

[Note: that is, the expression &(qualified-id), where the qualified-id is enclosed in parentheses, does not form an expression of type “pointer to member.” Neither does qualified-id, because there is no implicit conversion from a qualified-id for a nonstatic member function to the type “pointer to member function” as there is from an lvalue of function type to the type “pointer to function” (4.3). Nor is &unqualified-id a pointer to member, even within the scope of the unqualified-id’s class. ]


I just got two interesting topics discussing this, especially @Johannes's answer is a nice read here:

and this one as well:

Which also means this topic should be voted close, for it seems to be a duplicate.

Community
  • 1
  • 1
Nawaz
  • 353,942
  • 115
  • 666
  • 851
  • I disagree about this question being a dupe of those questions, see here: http://meta.stackexchange.com/questions/109993/guidelines-for-closing-questions-as-exact-duplicate – John Dibling Dec 08 '11 at 18:42