10

Here is a sample of code that annoys me:

class Base {
  protected:
    virtual void foo() = 0;
};

class Derived : public Base {
  private:
    Base *b; /* Initialized by constructor, not shown here
                Intended to store a pointer on an instance of any derived class of Base */

  protected:
    virtual void foo() { /* Some implementation */ };
    virtual void foo2() {
      this->b->foo(); /* Compilator sets an error: 'virtual void Base::foo() is protected' */
    }
};

How do you access to the protected overrided function?

Thanks for your help. :o)

Bernard Rosset
  • 4,523
  • 6
  • 27
  • 29
  • 7
    I don't think your implementation is quite right. Why do you have an instance of Base as a member variable? this->b->foo() would be trying to call a pure virtual method. – GWW Jan 12 '11 at 18:26
  • 1
    This program shouldn't compile. You cannot instantiate an abstract class....Unless `b` is pointing to an instance of some other class derived from `Base`. – 341008 Jan 12 '11 at 18:34
  • I omitted precision: the Derived::b attribute is intended to store any instance of derived classes from Base – Bernard Rosset Jan 13 '11 at 10:44
  • See also https://stackoverflow.com/questions/3247671/accessing-protected-members-in-a-derived-class (that's about members instead of methods, but they are not very different) – user202729 Oct 13 '18 at 07:21
  • 2
    C++ calls them member functions, not methods (although some people use the latter, but in my experience that just leads to linguistic arguments), and the concepts are the same for member functions and member variables, so: duplicate of [Accessing protected members in a derived class](https://stackoverflow.com/questions/3247671/accessing-protected-members-in-a-derived-class) – underscore_d Oct 13 '18 at 19:02

6 Answers6

12

Protected members in a base-class are only accessible by the current object.
Thus, you are allowed to call this->foo(), but you are not allowed to call this->b->foo(). This is independent of whether Derived provides an implementation for foo or not.

The reason behind this restriction is that it would otherwise be very easy to circumvent protected access. You just create a class like Derived, and suddenly you also have access to parts of other classes (like OtherDerived) that were supposed to be inaccessible to outsiders.

Bart van Ingen Schenau
  • 15,488
  • 4
  • 32
  • 41
  • 1
    Thanks, I now clearly understand the reasons of the restriction... That would be a security hole... big one! – Bernard Rosset Jan 13 '11 at 10:47
  • 8
    Please don't think of it as a security hole. Access modifiers do not provide any security, you could just read the memory location if you wanted the data. – DrYap Apr 06 '14 at 20:25
  • right, this isn't about "security" but instead about telling users which parts of the class they can use and rely on (i.e. which parts are not implementation details that might vanish/change at any moment). sure, they shouldn't read that stuff, and will have to use acrobatics with stuff like `offsetof` to do so, but it's definitely not about security in the sense of physically preventing access to data - only documenting intended usage, semantics, and stability of the API. – underscore_d Oct 13 '18 at 19:00
7

Normally, you would do it using Base::foo(), which refers to the base class of the current instance.

However, if your code needs to do it the way you're trying to and it's not allowed, then you'll need to either make foo() public or make Derived a friend of Base.

Jonathan Wood
  • 65,341
  • 71
  • 269
  • 466
5

One solution would be to declare a static protected function in Base that redirects the call to the private / protected function (foo in the example).

Lets say:

class Base {
protected:
    static void call_foo(Base* base) { base->foo(); }
private:
    virtual void foo() = 0;
};

class Derived : public Base {
private:
    Base* b;
protected:
    virtual void foo(){/* Some implementation */};
    virtual void foo2()
    {
        // b->foo(); // doesn't work
        call_foo(b); // works
    }
};

This way, we don't break encapsulation because the designer of Base can make an explicit choice to allow all derived classes to call foo on each other, while avoiding to put foo into the public interface or explicitly turning all possible subclasses of Base into friends.

Also, this method works regardless of whether foo is virtual or not, or whether it is private or protected.

Here is a link to a running version of the code above and here another version of the same idea with a little more business logic.

Clemens Sielaff
  • 708
  • 10
  • 15
1

It's a bit fragile, but with the classes you defined here, won't this work?

virtual void foo2() {
  reinterpret_cast<Derived *>(this->b)->foo(); 
}

The reinterpret_cast points at the VTABLE for the base object, and calls it through this members accessor.

Anthony Wieser
  • 4,351
  • 1
  • 23
  • 25
0

You call base functions explicitly with the scope operator (Base::foo()). But in this case, the Base class doesn't define foo (it's pure virtual), so there's actually no function to execute when you say this->b->foo(); since b is a pointer to Base and not Derived.

Gemini14
  • 6,246
  • 4
  • 28
  • 32
  • 1
    But the OP's code doesn't refer to the base class of the current instance. He's accessing another instance, which presumably is a derived class that implements the pure-virtual function. (Otherwise, the instance could not be created.) – Jonathan Wood Jan 12 '11 at 18:36
  • @Jonathan Wood I understand what you're saying, but just going from the code he's posted, it looks like he's trying to instantiate an abstract base class (Base) and call a pure virtual function (Base::foo()), which is a no-no (as GWW and 341008 also mentioned above). – Gemini14 Jan 12 '11 at 18:46
0

How do you access to the protected overrided function?

--- from where?

You can access a protected member only via inheritance (apart from the methods of the same class). Say for example you have a class Derived1 which inherits from Derived, then objects of Derived1 can call foo().

EDIT: MSDN article on protected access specifier.

yasouser
  • 5,113
  • 2
  • 27
  • 41