Access to method pointer to protected method?

Question

This code:

class B {
 protected:
  void Foo(){}
}

class D : public B {
 public:
  void Baz() {
    Foo();
  }
  void Bar() {
    printf(\"%x\\n\", &B::F         


        

Answer 1

Your post doesn't answer "Why can I call a protected method but not take its address?"

class D : public B {
 public:
  void Baz() {
    // this line
    Foo();
    // is shorthand for:
    this->Foo();
  }
  void Bar() {
    // this line isn't, it's taking the address of B::Foo
    printf("%x\n", &B::Foo);

    // not D:Foo, which would work
    printf("%x\n", &D::Foo);

  }
}

Answer 2

Is there a way to mark something fully accessible from derived classes rather than only accessible from derived classes and in relation to said derived class?

Yes, with the passkey idiom. :)

class derived_key
{
    // Both private.
    friend class derived;

    derived_key() {}
};

class base
{
public:
    void foo(derived_key) {}
};

class derived : public base
{
public:
    void bar() { foo(derived_key()); }
};

Since only derived has access to the contructor of derived_key, only that class can call the foo method, even though it's public.
The obvious problem with that approach is the fact, that you need to friend every possible derived class, which is pretty error prone. Another possible (and imho better way in your case) is to friend the base class and expose a protected get_key method.

class base_key
{
    friend class base;

    base_key() {}
};

class base
{
public:
    void foo(base_key) {}

protected:
    base_key get_key() const { return base_key(); }
};

class derived1 : public base
{
public:
    void bar() { foo(get_key()); }
};

class derived2 : public base
{
public:
    void baz() { foo(get_key()); }
};

int main()
{
  derived1 d1;
  d1.bar(); // works
  d1.foo(base_key()); // error: base_key ctor inaccessible
  d1.foo(d1.get_key()); // error: get_key inaccessible

  derived2 d2;
  d2.baz(); // works again
}

See the full example on Ideone.

Answer 3

You can take the address through D by writing &D::Foo, instead of &B::Foo.

See this compiles fine : http://www.ideone.com/22bM4

But this doesn't compile (your code) : http://www.ideone.com/OpxUy

---

Why can I call a protected method but not take its address?

You cannot take its address by writing &B::Foo because Foo is a protected member, you cannot access it from outside B, not even its address. But writing &D::Foo, you can, because Foo becomes a member of D through inheritance, and you can get its address, no matter whether its private, protected or public.

&B::Foo has same restriction as b.Foo() and pB->Foo() has, in the following code:

void Bar() {
    B b;
    b.Foo();     //error - cannot access protected member!
    B *pB = this;
    pB->Foo();   //error - cannot access protected member!
  }

See error at ideone : http://www.ideone.com/P26JT

Answer 4

Why can I call a protected method but not take its address?

This question has an error. You cannot do a call either

B *self = this;
self->Foo(); // error either!

As another answer says if you access the non-static protected member by a D, then you can. Maybe you want to read this?

---

As a summary, read this issue report.

Answer 5

This is because an object of a derived class can only access protected members of a base class if it's the same object. Allowing you to take the pointer of a protected member function would make it impossible to maintain this restriction, as function pointers do not carry any of this information with them.

Answer 6

I believe protected doesn't work the way you think it does in C++. In C++ protected only allows access to parent members of its own instance NOT arbitrary instances of the parent class. As noted in other answers, taking the address of a parent function would violate this.

If you want access to arbitrary instances of a parent, you could have the parent class friend the child, or make the parent method public. There's no way to change the meaning of protected to do what you want it to do within a C++ program.

But what are you really trying to do here? Maybe we can solve that problem for you.