在自动范围内使用实例时需要“公共”访问修饰符

Question

Suppose we have two classes, one derived from other and it contains only one virtual non-pure method like this:

class Base
{
public:
    virtual void method()
    {
        cout << "method() called from Base" << endl;
    }
};


class Derived : public Base
{
public:
    void method()
    {
        cout << "method() called from Derived" << endl;
    }
};


int main()
{
    Base *instance1 = new Derived();
    instance1->method();

    Derived derived;
    derived.method();
}

Why, if we do not specify explicitly "public" access modifier in Derived class (so, compiler assumes that it's private) it wouldn't compile? Why instantiation way(via pointer and via regular variable) does affect to the visibility scope? Is there any rationale regarding this behavior?

Many thanks!

Answer 1

If you don't write public: then it's as if you've written private: . If you're asking why the language doesn't automatically switch to public: for Derived::method() (because it overrides Base::method() which is already public)… well, it could! This would be possible.

However, it would also be extremely confusing and misleading when reading the code. As a programmer I much prefer that my class definition isn't fundamentally altered behind my back like that.

The compiler throws out an error (as you've discovered) allowing me to make the change myself as I deem appropriate (whether that's making Derived::method() public, or Base::method() private!), which in my opinion is by far the best outcome.

If instead you're asking why a difference in visibility even matters at all, then that seems fairly obvious, does it not? If the user were calling a function through the Base class interface, in which method() is public, and this ended up automatically invoking a private function in a derived class, that violates the contract of the derived class. And because it's only the names that are protected by these visibility rules, the language adds an extra check for overridden methods to extend that protection as much as possible in the case of virtual function dispatch.

Answer 2

Something very similar is given as an example in the standard where the rules for these things are specified [class.access.virt]:

1 The access rules (Clause 11) for a virtual function are determined by its declaration and are not affected by the rules for a function that later overrides it.

[ Example:

 class B { public: virtual int f(); }; class D : public B { private: int f(); }; void f() { D d; B* pb = &d; D* pd = &d; pb->f(); // OK: B::f() is public, // D::f() is invoked pd->f(); // error: D::f() is private } 

— end example ]

2 Access is checked at the call point using the type of the expression used to denote the object for which the member function is called (B* in the example above). The access of the member function in the class in which it was defined (D in the example above) is in general not known.

The above answer both your questions:

1. Why does it not compile - as per rule 2 above access is checked using the type of the expression (ie the static not dynamic type)
2. What is the rationale - again as described above it is generally not known what the dynamic type is. To demonstrate, consider this: You can link new derived classes to an existing code defining a base class without recompiling this code: then clearly it would have no chance of determining the access controls of the derived (which didn't even exist when it was compiled).