0

pointer-to-(data)members are illustrated here(from this answer: https://stackoverflow.com/a/670744/4416169 )

#include <iostream>
using namespace std;

class Car
{
public:
    void carFunc(){}//added this myself
    int speed;
};

int main()
{
    int Car::*pSpeed = &Car::speed;

    Car c1;
    c1.speed = 1;       // direct access
    cout << "speed is " << c1.speed << endl;
    c1.*pSpeed = 2;     // access via pointer to member
    cout << "speed is " << c1.speed << endl;
    return 0;
}

Would it be useful, and atleast partially accurate, for the sake of memorizing the behavior of these pointers-to-data-members, to think about them as storing the memory offset to the pointed data member? This memory offset would then be added to the memory location of the specific class instance that is used to access the pointer-to-data-member in that specific instance.

If this mnemonic is flawed, what other better mnemonic is there for pointer-to-data-members?

Then there is the case of pointer-to-member-functions:

void (Car::*fptr)() = &Car::carFunc;

Would it be correct to imagine these pointer-to-member-functions as simple and clean function pointers pointing to a specified member function taking and returning whatever is specified BUT in addition and implicitly also taking a this pointer from the instance calling them?

Matias Chara
  • 921
  • 6
  • 21
  • 1
    Personally, I think these mnemonics are useful and fairly accurate. But I guess that's a matter of taste. – n314159 Jul 15 '20 at 18:41

2 Answers2

2

Would it be useful, and atleast partially accurate, for the sake of memorizing the behavior of these pointers-to-data-members, to think about them as storing the memory offset to the pointed data member?

Sure.

Would it be correct to imagine these pointer-to-member-functions as simple and clean function pointers

As far as how they are used, pointers to member functions are indeed quite similar to function pointers are used except for the syntax. However, this "mnemonic" fails when considering virtual functions. A mere pointer to function is not sufficient to make that work.

eerorika
  • 232,697
  • 12
  • 197
  • 326
  • if you could elaborate on the virtual functions part please. – Matias Chara Jul 15 '20 at 19:12
  • 2
    @MatiasChara This goes into implementation details that may in theory differ between compilers and may be a bit inaccurate, but: Indirection through function pointer is essentially same as indirecting through a poiter; you just need address of the first instruction and off you go. Indirection through pointer to member function (of polymorphic class) involves first indirecting through the object reference to access its virtual function function pointer pointing to a virtual function table of the dynamic type, and then call the function according to that table. – eerorika Jul 15 '20 at 19:16
  • Multiple inheritance is another thing that makes pointers-to-member-functions strange. Raymond Chen wrote a good article on the MSVC implementation on his blog a long time ago: [Pointers to member functions are very strange animals](https://devblogs.microsoft.com/oldnewthing/20040209-00/?p=40713). – Miles Budnek Jul 15 '20 at 19:36
1

I would say, while it could be a tempting mnemonic, I would caution against using it.

Pointers to members are quite different from the regular pointers, and one would benefit from having this distinction set in their mind early on. Might save a lot of grief later. For example,

PtrType1 p = getPtrType1P();
PtrType2 z = reinterpret_cast<PtrType2>(p);

PtrType1 k = reinterpret_cast<PtrType1>(z);

Would yield perfectly usable k as long as PtrType1 and PtrType2 are regular pointers. But if one of them is a member pointer, this is no longer valid code. Keep in mind, pointers to virtual function members usually are 16 bytes long (double the size of regular pointer).

I think, the better mnemonic is to understand pointers to members as what they are - a way to indirectly access a member of the class given a pointer to it.

SergeyA
  • 61,605
  • 5
  • 78
  • 137