Changing access scope of virtual functions

[Kira Yamato]

Two questions concerning overriding virtual functions. First question
should have a clear answer, while the second question is more of an
opinion question.


1) Does the C++ standard say anything regarding changing the access
scope when overriding virtual functions?

For example:

class A { protected: virtual void foo(); };
class B : public A { public: virtual void foo(); };
class C : public A { private: virtual void foo(); };

I've tested that in g++ 4.0.1 the compiler does not complain at all.
But that just may be an implementation thing.

Of course, I am aware of private and protected inheritance, which will
implicitly demote the access scope of every base methods in the derived
class. So, I would think that demote access scope has a well-defined
behavior in the C++ standard.

But what about promoting access scope? Is it ever a dangerous thing to do?


2) From a software design perspective, is it ever a good idea to
promote or demote the access scope of a virtual function? Or is it
like one of those "permissible but not beneficial" features of C++?

In java, you can only promote access scope, i.e., you cannot decrease
the accessibility of a method in the derived class that overrides one
in the base class. Of course, that is only because of the way java's
security model works.


Thanks for any input.

 

[James Kanze]

Two questions concerning overriding virtual functions. First
question should have a clear answer, while the second question
is more of an opinion question.

1) Does the C++ standard say anything regarding changing the
access scope when overriding virtual functions?

No. Access is a property of the class interface, and depends
only on the static type. A derived class is free to define
whatever interface it wants, including whatever access it cares
to grant. (And it's not access scope, but simply access, or
access rights. It has absolutely nothing to do with scope.)

For example:

class A { protected: virtual void foo(); };
class B : public A { public: virtual void foo(); };
class C : public A { private: virtual void foo(); };

I've tested that in g++ 4.0.1 the compiler does not complain at all.
But that just may be an implementation thing.

Of course, I am aware of private and protected inheritance, which will
implicitly demote the access scope of every base methods in the derived
class. So, I would think that demote access scope has a well-defined
behavior in the C++ standard.

The access specifiers on inheritance have a somewhat different
role; inheriting privately means that a user cannot use an
object of derived type as a base. (In particular, the implicit
derived to base conversions are disactivated.)

But what about promoting access scope? Is it ever a dangerous
thing to do?

The derived class is free to define its own contracts, including
making functions available which weren't available in the base
class. Whether it is a good idea or not is another question.

2) From a software design perspective, is it ever a good idea to
promote or demote the access scope of a virtual function?

Most of the time, all of the virtual functions will be private,
and should probably remain that way throughout the hierarchy.
There are exceptions, however.

Or is it like one of those "permissible but not beneficial"
features of C++?

There are doubtlessly cases where increasing access is
reasonable (i.e. private in the base class, but public in the
derived). Reducing access seems less useful (unless the
inheritance is private to begin with). But there doesn't seem
to be any valid reason to ban it, either, and the general
principle of C++ is to not ban anything without a very good
reason.

In java, you can only promote access scope, i.e., you cannot
decrease the accessibility of a method in the derived class
that overrides one in the base class. Of course, that is only
because of the way java's security model works.

The logic, here, of course, is that the more limited access is
only apparent---you can always access the function by converting
your pointer to a pointer to base. I think some C++ compilers
warn in this case as well. On the other hand, if you inherit
privately, it often makes good sense to restrict the access more
in the derived class.