C++ – Accessing Virtual Protected Functions of Base Class in Derived Class

access-modifierscc++11inheritance

Consider the following:

#include <iostream>

class Base {
    public:

        void go(){this->doSomething();}

    protected:
        virtual void doSomething(){std::cout << "base";}
};

class DerivedA : public Base {
    protected:
        void doSomething() override {std::cout << "a";}
};

class DerivedB : public Base {
    public:
        Base * basePtr;

        DerivedB()
          :basePtr(new DerivedA())
        {}

    protected:
        void doSomething() override {basePtr->doSomething();} // wont compile
};

int main(int , char *[])
{
   DerivedB b;
   b.go();
}

doSomething() in the DerivedB subclass will not compile, but I do not understand why this behavior exists! I am trying to access a virtual protected member function of my base class, which I would have thought would be allowed.

http://en.cppreference.com/w/cpp/language/access

In the section on protected member access, it says

"A protected member of a class Base can only be accessed
1) by the members and friends of Base
2) by the members and friends (until C++17) of any class derived from Base, but only when operating on an object of a type that is derived from Base (including this)"

According to point 2, if I cast down to the subclass (DerivedA), this would be allowed but I would then be in conflict with the condition that I am accessing a protected member function of a different class (which is not a base class, and would also not compile). Worse, if I knew the sub class type of the derived object, I could still not access it even if I cast to its common base.

Why is this behavior enforced? I assume it is probably going to be a side effect of allowing multiple inheritance etc but I can't think of exactly what it would be. It's annoying because now I have to make a public interface for something which is and should only be used by base or derived classes, which goes against the point of inheritance and access modifiers.

Best Answer

I am trying to access a virtual protected member function of my base class

Yes, but you are trying to do this via another object basePtr, not this object. And that other object is a Base. You somehow mix up classes (types) with objects (instances) of that class. You shouldn't be able to call a protected member function of a Base object when you're not 'in' that same object. And you aren't. The fact that you are executing code inside your derived class doesn't matter here. The access level is not being checked against the instance this of your derived class, but against the instance basePtr you want to access.

And it's fine the way it is. Designers of class Base don't want people to call doSomething on objects of class Base. No matter from where! That's what the word protected says. They are however fine by having doSomething be called from the implementation of instances that are (in the the sense of the is-a-relationship of inheritance) Bases, that means from instances of derived classes.

Related Solutions

Object-oriented – Filesystem like permissions for C++ type-members

Rephrasing the problem a bit:

I have an instance of MySpecialObject
an instance of JLP wants to call the methods of MySpecialObject
an instance of BEV wants to read the public data of MySpecialObject
the instance of JLP shouldn't be able to read public data and the BEV shouldn't be able to call member functions

This should be as type-safe as possible.

A solution I see involves wrappers :)

you write the code for MySpecialObject as you would normally, ignoring this extra requirement
you write a wrapper for each aspect of your class you wish to restrict. Say, MySpecialObject_Read and MySpecialObject_Execute.
these wrappers forward the requests (method calls, getter/setters) to an underlying shared_ptr of MySpecialObject
your MySpecialObject, MySpecialObject_Read and MySpecialObject_Execute classes each have (as needed) a "convert to ..." method. This method returns an appropriate wrapper over the underlying MySpecialObject

This solution provides a type-safe accessor with the desired limitations.

Each client class can choose what kind of access it needs. (And since you write these classes, you know what access you need.) If that is not acceptable, you could add factories that only create wrappers with certain limitations depending on a "token". That token might be the RTTI information of the calling class instance, although this could be abused.

Does this solve the original problem?

EDIT:

Remember that since you are the programmer you can instantiate an A whenever you want. By adding your class to a friend list or whatever...

What this solution provides is a clearer interface. Removing the explicit conversions probably makes it safer but less flexible. But, since they are explicit, you can easily look for them in the code and treat them as signs your architecture has a flaw somewhere.

Specifically, you can have code like this:

shared_ptr<A> * a = new A(parameters);

A_read aRead(a);
A_execute aExec(a);
A_write aWrite(aExec);

logger->Log(aRead);
view->SetUserData(aWrite);
controller->Execute(aExec);

Here there is an explicit conversion between an execute wrapper and a write wrapper, but you can decide on this based on your specific requirements.

But, with little effort (knowing which conversions are valid), just by looking at the call locations you can see that (with confidence!):

the logger will not change the state of your A
the view will not call methods on your A (other than setters)

This is true even if those particular method calls end up calling hundreds of other methods, more than you'd like to examine by hand.

At the cost of a few thin wrappers you gain the ability to see at a glance what a particular function call will do with the parameters you send. This may help a lot during debugging by helping you eliminate some branches from your investigation and, in general, would help people trying to understand the program.

I couldn't really find other reasons for using this ACL idea, at least ones where the costs don't outweigh the benefits. However, it does seem more intuitive than the visitor solution mentioned in the other answer.

C++ Inheritance – Public vs Private Inheritance for Exposing Parent’s Methods

You can expose items that would otherwise have some kind of restricted access (i.e., private or protected) without writing a wrapper function by using the using directive:

class base {
public:
    base();
    virtual ~base();
    void do_something();
    void do_something_else();
private:
    // elided
};

class derived : private base {
public:
    derived();
    virtual ~derived();
    using base::do_something();
};

In the above, the derived class exposes base::do_something() as a public method, but not base::do_something_else().

Best Answer

Related Solutions

Object-oriented – Filesystem like permissions for C++ type-members

C++ Inheritance – Public vs Private Inheritance for Exposing Parent’s Methods

Related Topic