Private access in an implementation still allows public access in an abstract interface

[tron.thomas]

Please consider the following code:

class Abstract
{
public:
virtual ~Abstract() {}
virtual void Method() = 0;
};

class Concrete : public virtual Abstract
{
private:
virtual void Method() {}
};

void UseAbstract()
{
Concrete concrete;
Abstract& abstract = concrete;

abstract.Method();
}


The implementation for Abstract::Method provided in the Concrete class
is private even though the declaration of the method is public in the
derived base class. Yet, compiling the code on three different
compilers produces no errors or warnings. I think many developer might
find this surprising and puzzling. I, myself, am not sure what to
think of it.

The end effect is that the implementation for the Abstract class works
as expected. An instance of Concrete can be used as an Abstract
instance and it works as expected with respect to the Abstract
interface. Method is public for Abstract and can be accessed just
fine, even though it is private with respect to its Concrete
implementation.

However, it seems that there is something wrong, or at least worrisome
about the fact that this can be done.

What can people say about the correctness of this code?
If it is correct, what are the reasons classes are allow to behave this
way?

 

[John Carson]

Please consider the following code:

class Abstract
{
public:
virtual ~Abstract() {}
virtual void Method() = 0;
};

class Concrete : public virtual Abstract
{
private:
virtual void Method() {}
};

void UseAbstract()
{
Concrete concrete;
Abstract& abstract = concrete;

abstract.Method();
}


The implementation for Abstract::Method provided in the Concrete class
is private even though the declaration of the method is public in the
derived base class. Yet, compiling the code on three different
compilers produces no errors or warnings. I think many developer
might find this surprising and puzzling. I, myself, am not sure what
to think of it.

What object a reference refers to cannot always be known at compile time but
may instead only be known at run time. Access rules are enforced at compile
time, so access rules cannot depend on the object referred to. Instead, they
depend on the type of the reference, since this is known at compile time.
The type of abstract is "reference to Abstract" and Method() is public in
Abstract. Accordingly, access must be allowed.

 

[tron.thomas]

What object a reference refers to cannot always be known at compile time but
may instead only be known at run time. Access rules are enforced at compile
time, so access rules cannot depend on the object referred to. Instead, they
depend on the type of the reference, since this is known at compile time.
The type of abstract is "reference to Abstract" and Method() is public in
Abstract. Accordingly, access must be allowed.

Thanks John. That makes sense.

 

[Neil Cerutti]

Please consider the following code:

class Abstract
{
public:
virtual ~Abstract() {}
virtual void Method() = 0;
};

class Concrete : public virtual Abstract
{
private:
virtual void Method() {}
};

void UseAbstract()
{
Concrete concrete;
Abstract& abstract = concrete;

abstract.Method();
}


The implementation for Abstract::Method provided in the Concrete class
is private even though the declaration of the method is public in the
derived base class. Yet, compiling the code on three different
compilers produces no errors or warnings. I think many developer might
find this surprising and puzzling. I, myself, am not sure what to
think of it.

It is this way because the alternative seemed worse. The C++ designers
deemed it would be horrible if changing the access specification of a
member function somewhere in your class hierarchy could alter the
resolution of a virtual function call, or cause your program to no
longer compile. Consider multiple inheritance:

class B {
public:
virtual void foo();
};

class X: public B {
private:
void foo();
};

class Y: public B {
public:
void foo();
};

class Fubar: public X, Y {
public:
void foo();
};

In this hierarchy, under a rule that made the private foo in X
inaccessible, there would be no ambiguity in the following call in
function fnagn. It would have to resolve to the public override in B.

void fnagn(Fubar* f)
{
f->foo();
}

But if the access specification of foo in X were then changed to
public, suddenly your code would not even compile.

So the actual rules make your code more robust, in theory. The call to
foo in fnagn is ambiguous, despite foo in X being private.

 

[Phlip]

But if the access specification of foo in X were then changed to
public, suddenly your code would not even compile.

The other odious alternative enforces access at runtime. That would add
extra opcodes to all the virtual functions that don't need them.

The OP should research Design Patterns. Sometimes a method's access is a
valid technique.

 

[Phlip]

The other odious alternative enforces access at runtime. That would add
extra opcodes to all the virtual functions that don't need them.

The OP should research Design Patterns. Sometimes
changing!

a method's access is a
valid technique.

 

[Neil Cerutti]

It is this way because the alternative seemed worse. The C++ designers
deemed it would be horrible if changing the access specification of a
member function somewhere in your class hierarchy could alter the
resolution of a virtual function call, or cause your program to no
longer compile. Consider multiple inheritance:

class B {
public:
virtual void foo();
};

class X: public B {
private:
void foo();
};

class Y: public B {
public:
void foo();
};

class Fubar: public X, Y {
public:
void foo();
};

In this hierarchy, under a rule that made the private foo in X
inaccessible, there would be no ambiguity in the following call in
function fnagn. It would have to resolve to the public override in B.

void fnagn(Fubar* f)
{
f->foo();
}

It seems people got the point, but there were errors in my example code.

Fubar should not declare a function foo, and fnagn should receive
pointer to B.

 

[wkaras]

Please consider the following code:

class Abstract
{
public:
virtual ~Abstract() {}
virtual void Method() = 0;
};

class Concrete : public virtual Abstract
{
private:
virtual void Method() {}
};

void UseAbstract()
{
Concrete concrete;
Abstract& abstract = concrete;

abstract.Method();
}


The implementation for Abstract::Method provided in the Concrete class
is private even though the declaration of the method is public in the
derived base class. Yet, compiling the code on three different
compilers produces no errors or warnings. I think many developer might
find this surprising and puzzling. I, myself, am not sure what to
think of it.

The end effect is that the implementation for the Abstract class works
as expected. An instance of Concrete can be used as an Abstract
instance and it works as expected with respect to the Abstract
interface. Method is public for Abstract and can be accessed just
fine, even though it is private with respect to its Concrete
implementation.

However, it seems that there is something wrong, or at least worrisome
about the fact that this can be done.

What can people say about the correctness of this code?
If it is correct, what are the reasons classes are allow to behave this
way?

The rule of thumb is that only the names of things can be made private,
not the things themselves. I think the main reason for this is that
it's
not possible at (least currently) to have ironclad protection of
members
that could not be defeated with casts, and have no run-time overhead.

In the particular example you give, I think there are cases where it
could actually be useful. The purpose of private is for the designer
of the class to prevent class users from creating undesired
dependencies
on cretain specifics of the class definition. What the above code is
saying is "don't write any code for Concrete instances using 'method()'
that would not also work for all instances of Abstract".