Pointers to member functions - quick Q

This is a discussion on Pointers to member functions - quick Q within the C++ Programming forums, part of the General Programming Boards category; Hi, I know they're not used often and there are usually better options, but I thought I'd learn about them ...

  1. #1
    Registered User Stonehambey's Avatar
    Join Date
    Jan 2008
    Location
    Kent, UK
    Posts
    118

    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

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Registered User Stonehambey's Avatar
    Join Date
    Jan 2008
    Location
    Kent, UK
    Posts
    118
    Thanks, it's strange that SAMS C++ in 21 days 5th edition (printed 2005) fails to mention this...

    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

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Stonehambey View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,593
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by laserlight View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Registered User Stonehambey's Avatar
    Join Date
    Jan 2008
    Location
    Kent, UK
    Posts
    118
    Quote Originally Posted by laserlight View Post
    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

    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

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Registered User Stonehambey's Avatar
    Join Date
    Jan 2008
    Location
    Kent, UK
    Posts
    118
    Quote Originally Posted by matsp View Post
    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

  10. #10
    Chinese pâté foxman's Avatar
    Join Date
    Jul 2007
    Location
    Canada
    Posts
    404
    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.
    I hate real numbers.

  11. #11
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,593
    And correct me if I'm wrong.
    You are correct, though the most obvious demonstration would be to use sizeof.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  12. #12
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  13. #13

    Join Date
    Apr 2008
    Location
    USA
    Posts
    76
    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.)
    Last edited by rudyman; 09-01-2008 at 10:11 AM.

  14. #14
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    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.

  15. #15
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by rudyman View Post
    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(*)().
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Modules and Member Functions
    By arrgh in forum C++ Programming
    Replies: 2
    Last Post: 05-07-2008, 02:46 AM
  2. issue with member functions
    By Chaplin27 in forum C++ Programming
    Replies: 4
    Last Post: 09-27-2006, 09:18 PM
  3. Problem with Visual C++ Object-Oriented Programming Book.
    By GameGenie in forum C++ Programming
    Replies: 9
    Last Post: 08-29-2005, 11:21 PM
  4. Passing pointers between functions
    By heygirls_uk in forum C Programming
    Replies: 5
    Last Post: 01-09-2004, 05:58 PM
  5. Replies: 4
    Last Post: 11-23-2003, 06:15 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21