Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Should 'public virtual' always become 'private virtual'? & using private inheritance

Reply
Thread Tools

Should 'public virtual' always become 'private virtual'? & using private inheritance

 
 
Dag Henriksson
Guest
Posts: n/a
 
      02-03-2004
"Uncle Bob (Robert C. Martin)" <(E-Mail Removed)> skrev i
meddelandet news:(E-Mail Removed)...

> No, probably because it won't compile. You can't make a derivative
> member less accessible than a base member.


What do you mean by that? You certainly can do:

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

You must have meant something else, but what?

--
Dag Henriksson


 
Reply With Quote
 
 
 
 
Uncle Bob (Robert C. Martin)
Guest
Posts: n/a
 
      02-03-2004
"Dag Henriksson" <(E-Mail Removed)> might (or might not)
have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :

>"Uncle Bob (Robert C. Martin)" <(E-Mail Removed)> skrev i
>meddelandet news:(E-Mail Removed)...
>
>> No, probably because it won't compile. You can't make a derivative
>> member less accessible than a base member.

>
>What do you mean by that? You certainly can do:
>
>class B
>{
>public:
> virtual void foo() {}
>};
>class D : public B
>{
>private:
> virtual void foo() {}
>};


Can you?

I don't doubt that there are some compilers that will compile it; but
I thought it was illegal in the language. I didn't think you could
use inheritance to restrict accessibility. Indeed, there is a special
mechanism (the using declaration) to make variables and functions that
are private in the base, public in a derivative.

It seems to me that making foo private in the derivative leads to
ambiguities. Consider:

D d;
d.foo();

Should the compiler complain that foo is private in D? Or should the
compiler implicitly cast the D& to a B& where foo is public?
It's been a long time since I checked this kind of thing though, so
maybe the language standard resolved this in a way that allowed it.
Robert C. Martin | "Uncle Bob"
Object Mentor Inc. | unclebob @ objectmentor . com
501 N. Riverside Dr.| Tel: (800) 338-6716
Suite 206 | Fax: (847) 775-8174 | www.objectmentor.com
| | www.XProgramming.com
Gurnee, IL, | Training and Mentoring | www.junit.org
60031 | OO, XP, Agile, C++, Java, C# | http://fitnesse.org
 
Reply With Quote
 
 
 
 
Rod Davison
Guest
Posts: n/a
 
      02-03-2004
On Tue, 03 Feb 2004 09:43:19 +0100, Dag Henriksson wrote:

> "Uncle Bob (Robert C. Martin)" <(E-Mail Removed)> skrev
> i meddelandet news:(E-Mail Removed)...
>
>> No, probably because it won't compile. You can't make a derivative
>> member less accessible than a base member.

>
> What do you mean by that? You certainly can do:
>
> class B
> {
> public:
> virtual void foo() {}
> };
> class D : public B
> {
> private:
> virtual void foo() {}
> };
>
> You must have meant something else, but what?


Actually, the original example does not compile. I tried it to see what
sort of error it might generate and my compiler got a problem with the
virtual function table. However, I think you missed the point of Robert
Martins comment.

It is not a syntactic rule of C++ that you should not make a baes class
public member private in a derived class, but an OOP principle that you
should not make the interface of a derived class a strict subset of the
interface of the base class. Violating this principle can result in two
undesirable outcomes:

1. Either code that does not compile like the original example because of
the compiler being unable to resolve function references.

2. Code that compiles, like your example, and produces bad results.

What are bad results? If we flesh out your classes like this:

class B
{
public:
virtual void foo() { cout <<"Base" << endl;}
};
class D : public B
{
private:
virtual void foo() { cout <<"Derived" << endl;}
};

so we can see which version is being called, then the code

int main() {
D *d = new D();
B *b = d;
b->foo();
// d->foo(); this line does NOT compile
}
}
produces the output "Derived" when it runs.

We have broken the interface of B (or D -- take your pick). We can have
broken encapsulation for d and we do not get the expected behavior. The
problem is that looking at the combination of inheritance and access
restriction means that the use of the base class pointer makes the
reference to foo() ambiguous. The compiler chose one option, I may have
intended another.

Java, on the other hand, has opted to make violating this OOP principle
impossible by enforcing it with a syntactic constraint -- if you tried to
compile this code in Java, it would not but would generate the error
"Cannot reduce the visibility of the inherited method from base".


I think Robert Martin's comment still stands but perhaps I would have
said:

>> No, probably because it won't compile. You shouldn't make a derivative
>> member less accessible than a base member.


I think the point to remember about C++, and any programming language for
that matter, is that just because the language allows you to do something
does not mean that it is good code. I would never allow any code like your
example to be used in any project I was working on because of the
potential for a down the road disaster. ("Gee, it always worked before
without any problems...").


--
..................................................
2 + 2 = 5 (for sufficiently large values of 2)

Rod Davison - Critical Knowledge Systems Inc.

 
Reply With Quote
 
Dag Henriksson
Guest
Posts: n/a
 
      02-03-2004
"Uncle Bob (Robert C. Martin)" <(E-Mail Removed)> skrev i
meddelandet news:(E-Mail Removed)...
> "Dag Henriksson" <(E-Mail Removed)> might (or might not)
> have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :
>
> >"Uncle Bob (Robert C. Martin)" <(E-Mail Removed)> skrev i
> >meddelandet news:(E-Mail Removed)...
> >
> >> No, probably because it won't compile. You can't make a derivative
> >> member less accessible than a base member.

> >
> >What do you mean by that? You certainly can do:
> >
> >class B
> >{
> >public:
> > virtual void foo() {}
> >};
> >class D : public B
> >{
> >private:
> > virtual void foo() {}
> >};

>
> Can you?
>
> I don't doubt that there are some compilers that will compile it; but
> I thought it was illegal in the language. I didn't think you could
> use inheritance to restrict accessibility. Indeed, there is a special
> mechanism (the using declaration) to make variables and functions that
> are private in the base, public in a derivative.
>
> It seems to me that making foo private in the derivative leads to
> ambiguities. Consider:
>
> D d;
> d.foo();
>
> Should the compiler complain that foo is private in D? Or should the
> compiler implicitly cast the D& to a B& where foo is public?


The compiler should complain that foo is private in D.

I think the text and example in 11.6p1 makes this clear:
*******************************************
11.6 Access to virtual functions

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

--
Dag Henriksson


 
Reply With Quote
 
Dag Henriksson
Guest
Posts: n/a
 
      02-03-2004
"Rod Davison" <(E-Mail Removed)> skrev i meddelandet

> Actually, the original example does not compile.


The only syntactic error I found in the original example was multiple
declarations of myPublicInterface1().

I totally agree with Bob and you that the design is far from optimal. I was
just curious about what the syntactic error Bob pointed out was.

--
Dag Henriksson


 
Reply With Quote
 
Avner Ben
Guest
Posts: n/a
 
      02-03-2004
Uncle Bob (Robert C. Martin) wrote:
> "Dag Henriksson" <(E-Mail Removed)> might (or might not)
>>...
>>What do you mean by that? You certainly can do:
>>
>>class B
>>{
>>public:
>> virtual void foo() {}
>>};
>>class D : public B
>>{
>>private:
>> virtual void foo() {}
>>};

>...
> I don't doubt that there are some compilers that will compile it; but
> I thought it was illegal in the language...


To the best of my Knowledge, this is legal in C++. In fact I once New a
developer that made a whole methodology out of it. Bear in mind that if
the function is late-bound through a base pointer. Only the base access
control is Known.

This is not the only peculiarity in the C++ inheritance system. For
example, you can also change a default argument value in a virtual
function override. the default you get will depend upon the level of
pointer used (rather error prone).

Avner.
 
Reply With Quote
 
Tsolak Petrosian
Guest
Posts: n/a
 
      02-03-2004
Simple.

You are implementing a type and trying to hide it.
Why? You could not implement in at all in the first place.

If you need to change the definition of derived class's type, then
define another type.

If you need to partially implement the type, then implement the needed
methods and have others to be as stubs or throw an exception.

There is no other good reason to make virtual functions as private.

Tsolak Petrosian
 
Reply With Quote
 
Nick Hounsome
Guest
Posts: n/a
 
      02-03-2004

"Uncle Bob (Robert C. Martin)" <(E-Mail Removed)> wrote in
message news:(E-Mail Removed)...
> "Dag Henriksson" <(E-Mail Removed)> might (or might not)
> have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :
>
> >"Uncle Bob (Robert C. Martin)" <(E-Mail Removed)> skrev i
> >meddelandet news:(E-Mail Removed)...
> >
> >> No, probably because it won't compile. You can't make a derivative
> >> member less accessible than a base member.

> >
> >What do you mean by that? You certainly can do:
> >
> >class B
> >{
> >public:
> > virtual void foo() {}
> >};
> >class D : public B
> >{
> >private:
> > virtual void foo() {}
> >};

>
> Can you?
>
> I don't doubt that there are some compilers that will compile it; but
> I thought it was illegal in the language. I didn't think you could
> use inheritance to restrict accessibility. Indeed, there is a special
> mechanism (the using declaration) to make variables and functions that
> are private in the base, public in a derivative.
>
> It seems to me that making foo private in the derivative leads to
> ambiguities. Consider:
>
> D d;
> d.foo();
>
> Should the compiler complain that foo is private in D? Or should the
> compiler implicitly cast the D& to a B& where foo is public?
> It's been a long time since I checked this kind of thing though, so
> maybe the language standard resolved this in a way that allowed it.


It is quite important that accessability is not considered until after name
lookup.
I think this is so that changing the accessability of a method wont break
client code.

> Robert C. Martin | "Uncle Bob"
> Object Mentor Inc. | unclebob @ objectmentor . com
> 501 N. Riverside Dr.| Tel: (800) 338-6716
> Suite 206 | Fax: (847) 775-8174 | www.objectmentor.com
> | | www.XProgramming.com
> Gurnee, IL, | Training and Mentoring | www.junit.org
> 60031 | OO, XP, Agile, C++, Java, C# | http://fitnesse.org



 
Reply With Quote
 
Robert C. Martin
Guest
Posts: n/a
 
      02-04-2004
On Tue, 3 Feb 2004 15:10:50 +0100, "Dag Henriksson"
<(E-Mail Removed)> wrote:

>"Uncle Bob (Robert C. Martin)" <(E-Mail Removed)> skrev i
>meddelandet news:(E-Mail Removed)...
>> "Dag Henriksson" <(E-Mail Removed)> might (or might not)
>> have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :
>>
>> >"Uncle Bob (Robert C. Martin)" <(E-Mail Removed)> skrev i
>> >meddelandet news:(E-Mail Removed)...
>> >
>> >> No, probably because it won't compile. You can't make a derivative
>> >> member less accessible than a base member.
>> >
>> >What do you mean by that? You certainly can do:
>> >
>> >class B
>> >{
>> >public:
>> > virtual void foo() {}
>> >};
>> >class D : public B
>> >{
>> >private:
>> > virtual void foo() {}
>> >};

>>
>> Can you?
>>
>> I don't doubt that there are some compilers that will compile it; but
>> I thought it was illegal in the language. I didn't think you could
>> use inheritance to restrict accessibility. Indeed, there is a special
>> mechanism (the using declaration) to make variables and functions that
>> are private in the base, public in a derivative.
>>
>> It seems to me that making foo private in the derivative leads to
>> ambiguities. Consider:
>>
>> D d;
>> d.foo();
>>
>> Should the compiler complain that foo is private in D? Or should the
>> compiler implicitly cast the D& to a B& where foo is public?

>
>The compiler should complain that foo is private in D.
>
>I think the text and example in 11.6p1 makes this clear:
>*******************************************
>11.6 Access to virtual functions
>
>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] 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.
>**********************************************


Live and learn. I could have sworn this was illegal. Perhaps it
used to be.


 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      02-04-2004
In article <(E-Mail Removed)>,
Robert C. Martin <(E-Mail Removed)> wrote:

> On Tue, 3 Feb 2004 15:10:50 +0100, "Dag Henriksson"
> <(E-Mail Removed)> wrote:
>
> >"Uncle Bob (Robert C. Martin)" <(E-Mail Removed)> skrev i
> >meddelandet news:(E-Mail Removed)...
> >> "Dag Henriksson" <(E-Mail Removed)> might (or might not)
> >> have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :
> >>
> >> >"Uncle Bob (Robert C. Martin)" <(E-Mail Removed)> skrev i
> >> >meddelandet news:(E-Mail Removed)...
> >> >
> >> >> No, probably because it won't compile. You can't make a derivative
> >> >> member less accessible than a base member.
> >> >
> >> >What do you mean by that? You certainly can do:
> >> >
> >> >class B
> >> >{
> >> >public:
> >> > virtual void foo() {}
> >> >};
> >> >class D : public B
> >> >{
> >> >private:
> >> > virtual void foo() {}
> >> >};
> >>
> >> Can you?
> >>
> >> I don't doubt that there are some compilers that will compile it; but
> >> I thought it was illegal in the language. I didn't think you could
> >> use inheritance to restrict accessibility. Indeed, there is a special
> >> mechanism (the using declaration) to make variables and functions that
> >> are private in the base, public in a derivative.
> >>
> >> It seems to me that making foo private in the derivative leads to
> >> ambiguities. Consider:
> >>
> >> D d;
> >> d.foo();
> >>
> >> Should the compiler complain that foo is private in D? Or should the
> >> compiler implicitly cast the D& to a B& where foo is public?

> >
> >The compiler should complain that foo is private in D.
> >
> >I think the text and example in 11.6p1 makes this clear:
> >*******************************************
> >11.6 Access to virtual functions
> >
> >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] 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.
> >**********************************************

>
> Live and learn. I could have sworn this was illegal. Perhaps it
> used to be.


It's illegal in Java, but not C++.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Become The master in computer hardware to become successfull shilla Computer Security 1 01-22-2011 06:19 PM
Private Inheritance and Publice Inheritance karthikbalaguru C++ 9 09-10-2007 01:05 PM
Private interface using reinterpret_cast vs. inheritance (long) news_mail_jpa@hotmail.com C++ 0 08-27-2005 10:01 AM
Private access modifier and Inheritance (Inheritance implementation in Java) maxw_cc Java 1 12-21-2003 11:38 AM



Advertisments