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]

"Marc Schellens" <m_*********@hotmail.com> wrote...

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

[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?

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.

But this kind of access is the point about polymorphism, isn't it?
Maybe I don't see the forest because of too many trees,
but how else could you make use of it?

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.

I meant a friend of the base class can access virtual private methods
of inherted classes through the base class ptr.

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.

I see. But could you give an example when this is wanted?

marc

[Victor Bazarov]

"Marc Schellens" <m_*********@hotmail.com> wrote...

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.

But this kind of access is the point about polymorphism, isn't it?
Maybe I don't see the forest because of too many trees,
but how else could you make use of it?

Nothing prevents you from using the function directly. Besides,
you may specify the class explicitly:

struct B {
virtual void foo();
};

struct D : B {
void foo();
};

int main() {
D d;
d.foo(); // will resolve to D::foo no matter what
d.B::foo(); // explicit specification of what to call
}

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.

I meant a friend of the base class can access virtual private methods
of inherted classes through the base class ptr.

Substituting the behaviour of the base class with derived's own
is the base (and the purpose) of polymorphism and has no bearing
on privacy and friendship. Even if the base class functions are
virtual and private, I can override those in the derived class
so that when the base class' member accesses those, the member
of the derived class will be called:

struct B {
void foo() { bar(); }
private:
virtual void bar();
};

struct D : B {
private: // doesn't matter at that point
void bar();
};

int main() {
B* pb = new D;
pb->foo(); // will call D::bar
}

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.

I see. But could you give an example when this is wanted?

Not off the top of my head, no.

Victor

[Victor Bazarov]

"Marc Schellens" <m_*********@hotmail.com> wrote...

>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.

But this kind of access is the point about polymorphism, isn't it?
Maybe I don't see the forest because of too many trees,
but how else could you make use of it?

Nothing prevents you from using the function directly. Besides,
you may specify the class explicitly:

struct B {
virtual void foo();
};

struct D : B {
void foo();
};

int main() {
D d;
d.foo(); // will resolve to D::foo no matter what
d.B::foo(); // explicit specification of what to call
}

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