Pointers to member functions - quick Q

Hi,

I know they're not used often and there are usually better options, but I thought I'd learn about them for the sake of completeness. I have a question about them.

I always thought that the name of a function is a pointer to that function, much like the name of an array is a pointer to the first element of the array. Is this not the case for member functions? For example, something like this won't compile

Code:

---


int (MyClass::*pFunc)() const = 0;

pFunc = MyClass::getMemberVariable;

---

But this will

Code:

---


int (MyClass::*pFunc)() const = 0;

pFunc = &MyClass::getMemberVariable; //need the "address of" operator here to make it work

---

Answers much appreciated

Thanks for your time :)

Stonehambey

Yes, that's one of the quirks in C++. In plain C (not C++), the name of a function always denotes the address of said function. In C++, the decision was to make it compulsory to have a & to get the address of a function - a good thing, I think - since a mistake I've made a few times is to use "Pascal syntax" to call functions that don't have any parameters:

Code:

---

void func(void)
{
....
}


int main()
{
  func;
  return 0:
}

---

This does absolutely nothing - and if you are LUCKY the compiler says "statment on line X has no effect".

--
Mats

Thanks, it's strange that SAMS C++ in 21 days 5th edition (printed 2005) fails to mention this...

Quote:

---

Just as an array name is a constant pointer to the first element of the array, a function name is a constant pointer to the function

---

Quote:

---

Originally Posted by Stonehambey

Thanks, it's strange that SAMS C++ in 21 days 5th edition (printed 2005) fails to mention this...

---

Yeah, well... That's obviously a direct copy from the "Sams C in 21 days" (or whatever C book it was copied from).

--
Mats

Quote:

---

Thanks, it's strange that SAMS C++ in 21 days 5th edition (printed 2005) fails to mention this...

---

That quote is with reference to free functions, which behave like C functions in this respect. matsp is talking about member functions, which is what you were asking about.

Quote:

---

Originally Posted by laserlight

That quote is with reference to free functions, which behave like C functions in this respect. matsp is talking about member functions, which is what you were asking about.

---

Yes, the C++ language does not break C-style function address when writing C code - so this only applies to class [and struct] member functions - which can not exist in standard C since standard C has no "class" type, and member functions are not allowed in C structs [struct and class is nearly the same thing in C++, but struct in C is restricted to "data", no member functions].

--
Mats

Quote:

---

Originally Posted by laserlight

That quote is with reference to free functions, which behave like C functions in this respect. matsp is talking about member functions, which is what you were asking about.

---

I see that now, but it still fails to mention anything

Quote:

---

Pointers to member functions are used in the same way as pointers to functions, except that they require an object of the correct class on which to invoke them

---

Here's a snippet from the following listing (15.10 in my book)

Code:

---

pFunc = Mammal::Speak;

---

For a novice programmer new to the concept, there is no reason at all for me to think I would need the address of operator when it came to member functions.

Thank god for forums like this :)

Stonehambey

It probably also relates to the fact that you very rarely need member function pointers - you probably can (and should) solve that problem with inheritance and virtual functions!

--
Mats

Quote:

---

Originally Posted by matsp

It probably also relates to the fact that you very rarely need member function pointers - you probably can (and should) solve that problem with inheritance and virtual functions!

--
Mats

---

Yeah, it states that quite explicitly a number of times :P

Quote:

---

the name of an array is a pointer to the first element of the array

---

Being pedantic, this is not exactly true. The name of an array... is an array. Like the name of an int... is an int. There is a conversion between an array and a pointer to what the array holds, and that makes it looks like the name of an array is a pointer on the first element of the array. What I really mean is just that there's a type difference between, example, an array of 5 int and a pointer to an int.

Code:

---

int array[5];      // Type is "int [5]"
int *pInt;        // Type is "int *"
int (*pArray)[5];  // Type is "int (*)[5]"

pInt = array;      // Correct, conversion from "int [5]" to "int *"
pArray = array;    // Incorrect, no conversion from "int [5]" to "int (*)[5]"
pArray = &array;  // Correct

---

Anyway. This has little implication. And correct me if I'm wrong. :p

Quote:

---

And correct me if I'm wrong.

---

You are correct, though the most obvious demonstration would be to use sizeof.

Of course the name of a function is also just the name of the function, and there just happens to be an implicit conversion from the name to the address. Language standards work better when such things are clearly defined.

I think it's really stupid how the compiler turns a function name into a pointer to a function. It's for that reason that something like this gets misinterpreted as a function prototype instead of a constructor call:

Code:

---

MyClass var ( MyClass() ); // (explicit) copy construction from a temporary

---

which should be illegal (as a function prototype) except that the compiler turns "MyClass()" into "MyClass (*) ()", which drastically changes the meaning of the code (and is even further from what the code is actually supposed to mean!)

EDIT: Also, why no reference-to-members?
(OK, done complaining.)

Furthermore, a name of a variable is just the name of the variable, and just happens to be evaluated to the value of the variable.

Quote:

---

Originally Posted by rudyman

I think it's really stupid how the compiler turns a function name into a pointer to a function. It's for that reason that something like this gets misinterpreted as a function prototype instead of a constructor call:

Code:

---

MyClass var ( MyClass() ); // (explicit) copy construction from a temporary

---

which should be illegal (as a function prototype) except that the compiler turns "MyClass()" into "MyClass (*) ()", which drastically changes the meaning of the code (and is even further from what the code is actually supposed to mean!)

---

Uh, that code is interpreted as

Code:

---

MyClass var( MyClass );

---

i.e. a declaration of a function called "var" that takes a MyClass object by valueand returns a MyClass object by value. There are no function pointers involved, and MyClass() is most definitely under absolutely no circumstances interpreted as MyClass(*)().

When I use GCC with Dev-C++, it gets interpreted as MyClass(*)(). Either way, the compiler changes the meaning of the code significantly (without telling you) from something that's semantically illegal (functions can't be passed by value) to something that's legal but very different in meaning.

Quote:

---

Either way, the compiler changes the meaning of the code significantly (without telling you) from something that's semantically illegal (functions can't be passed by value) to something that's legal but very different in meaning.

---

More like the code is interpreted in a way that the author may not expect, so the author is actually expressing a meaning contrary to his or her intention.

It looks you are right.

Isn't this feature inherited from C where the two following lines declare the same thing (and omit the name p, since a function can have unnamed arguments)?

Code:

---

void foo(int (*p)());
void foo(int p());

---

Yeah. And the point I'm trying to make is, that feature is useless aside from syntactic sugar and it only causes ambiguity and misinterpretation. If the compiler didn't do that, it would see that the function declarator was illegal and would (hopefully) treat it as a constructor instead.

But I guess compatibility deserves higher priority.