friends, private, break of encapsulation?

[Marc Schellens]

If I have a base class with a public virtual member function,
a child class will grand access to its overridden memeber function
even if its private in the child class, as the compliler cannot
know at compile time that the overridden function is called, right?
Doesn't that break encapsulation?
Same with friends of the base class.
Does it make sense to declare the method in the derived class as private
then at all?
A programmer only looking at the derived class might get a wrong
impression...
marc

 

[Victor Bazarov]

If I have a base class with a public virtual member function,
a child class will grand access to its overridden memeber function
even if its private in the child class, as the compliler cannot
know at compile time that the overridden function is called, right?

No. Only if accessed through a pointer to the base will the
function be executed. And the base class has explicitly given
access to anybody.

Doesn't that break encapsulation?

No, it does not.

Same with friends of the base class.

I am not sure I understand this statement. Friendship is not
inherited.

Does it make sense to declare the method in the derived class as private
then at all?

Depends on the situation.

A programmer only looking at the derived class might get a wrong
impression...

Please give an example of "getting wrong impression". The usual
reason to make final overriders private is to prevent them from
being used in non-polymorphic way.

Victor

 

[Victor Bazarov]

But thats not polymorphism, is it?
Or what would be the difference here without 'virtual'?

No difference, I suppose. Try making 'D::foo' private.
d.foo() will cause errors.

This example was meant to illustrate calling the function
directly and specifying the class in the call.

Victor