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

Discussion in 'C++' started by qazmlp, Jan 31, 2004.

  1. qazmlp

    qazmlp Guest

    class base
    {
    // other members
    public:
    virtual ~base()
    {
    }
    virtual void virtualMethod1()=0 ;
    virtual void virtualMethod2()=0 ;
    virtual void virtualMethod3()=0 ;
    } ;


    I derive a class from base. I want to make all the virtual functions
    as private.
    class derived : public base
    {
    // other members
    public:
    virtual ~derived()
    {
    }

    void myPublicInterface1() ;
    void myPublicInterface1() ;

    private:
    virtual void virtualMethod1()=0 ;
    virtual void virtualMethod2()=0 ;
    virtual void virtualMethod3()=0 ;
    } ;


    I did the above considering the facts that
    - in any case, the virtual functions will always be called through
    the base class pointer only
    - No. of public virtual interfaces should be reduced as much as
    possible

    Here are my questions:
    1)
    Can I consider this as a good design? If yes/no, why?

    2)
    How about
    class derived : private base
    {

    }
    instead of the above design, as anyway, all the inherited virtual
    functions need to be made as private ?

    Is this a correct design? If yes/no, why?


    3)
    What are the flaws in the above design and what do you suggest for
    improvements?
     
    qazmlp, Jan 31, 2004
    #1
    1. Advertising

  2. "qazmlp" <> skrev i en meddelelse
    news:...
    > class base
    > {
    > // other members
    > public:
    > virtual ~base()
    > {
    > }
    > virtual void virtualMethod1()=0 ;
    > virtual void virtualMethod2()=0 ;
    > virtual void virtualMethod3()=0 ;
    > } ;
    >
    >
    > I derive a class from base. I want to make all the virtual functions
    > as private.
    > class derived : public base
    > {
    > // other members
    > public:
    > virtual ~derived()
    > {
    > }
    >
    > void myPublicInterface1() ;
    > void myPublicInterface1() ;
    >
    > private:
    > virtual void virtualMethod1()=0 ;
    > virtual void virtualMethod2()=0 ;
    > virtual void virtualMethod3()=0 ;
    > } ;


    This has absolutely no value. Those functions are accesible anyway, you
    know.

    >
    >
    > I did the above considering the facts that
    > - in any case, the virtual functions will always be called through
    > the base class pointer only
    > - No. of public virtual interfaces should be reduced as much as
    > possible
    >
    > Here are my questions:
    > 1)
    > Can I consider this as a good design? If yes/no, why?


    No - because you do not reduce the number of public, virtual functions.
    >
    > 2)
    > How about
    > class derived : private base
    > {
    >
    > }
    > instead of the above design, as anyway, all the inherited virtual
    > functions need to be made as private ?
    >
    > Is this a correct design? If yes/no, why?


    This is not any better as base *b = new derived(...) will no longer compile.

    >
    >
    > 3)
    > What are the flaws in the above design and what do you suggest for
    > improvements?


    Use this scheme instead:
    class base
    {
    // other members
    virtual void virtualMethod1()=0 ;
    virtual void virtualMethod2()=0 ;
    virtual void virtualMethod3()=0 ;
    public:
    virtual ~base()
    {
    }
    void method1() { virtualMethod1();}
    void method2() { virtualMethod2();}
    void method3() { virtualMethod3();}

    };
     
    Peter Koch Larsen, Jan 31, 2004
    #2
    1. Advertising

  3. "qazmlp" <> wrote in message
    news:...
    > class base
    > {
    > // other members
    > public:
    > virtual ~base()
    > {
    > }
    > virtual void virtualMethod1()=0 ;
    > virtual void virtualMethod2()=0 ;
    > virtual void virtualMethod3()=0 ;
    > } ;
    >
    >
    > I derive a class from base. I want to make all the virtual functions
    > as private.
    > class derived : public base
    > {
    > // other members
    > public:
    > virtual ~derived()
    > {
    > }
    >
    > void myPublicInterface1() ;
    > void myPublicInterface1() ;
    >
    > private:
    > virtual void virtualMethod1()=0 ;
    > virtual void virtualMethod2()=0 ;
    > virtual void virtualMethod3()=0 ;
    > } ;
    >
    >
    > I did the above considering the facts that
    > - in any case, the virtual functions will always be called through
    > the base class pointer only
    > - No. of public virtual interfaces should be reduced as much as
    > possible
    >
    > Here are my questions:
    > 1)
    > Can I consider this as a good design? If yes/no, why?
    >


    Because public inheritance should mean IS-A which implies that
    you must provide at least as much if not more than the base class.

    > 2)
    > How about
    > class derived : private base
    > {
    >
    > }
    > instead of the above design, as anyway, all the inherited virtual
    > functions need to be made as private ?
    >
    > Is this a correct design? If yes/no, why?
    >


    Depends - they can't both be right because either a derived IS-A base or not
    and
    that depends on what derived and base actually are.

    >
    > 3)
    > What are the flaws in the above design and what do you suggest for
    > improvements?


    It's not a design at all because it doesn't define what base and derived
    actually are.
    Until you decide that you cannot make sensible decisions about how to
    implement them.

    You must either tell us what they are supposed to be or rewrite your
    question as
    one of a purely language nature rather than design.
     
    Nick Hounsome, Jan 31, 2004
    #3
  4. qazmlp

    Joe Guest

    Just curious......what is the advantage of lowering the number of public
    virtual methods? Thanks


    "Peter Koch Larsen" <> wrote in message
    news:HGPSb.81747$...
    >
    > "qazmlp" <> skrev i en meddelelse
    > news:...
    > > class base
    > > {
    > > // other members
    > > public:
    > > virtual ~base()
    > > {
    > > }
    > > virtual void virtualMethod1()=0 ;
    > > virtual void virtualMethod2()=0 ;
    > > virtual void virtualMethod3()=0 ;
    > > } ;
    > >
    > >
    > > I derive a class from base. I want to make all the virtual functions
    > > as private.
    > > class derived : public base
    > > {
    > > // other members
    > > public:
    > > virtual ~derived()
    > > {
    > > }
    > >
    > > void myPublicInterface1() ;
    > > void myPublicInterface1() ;
    > >
    > > private:
    > > virtual void virtualMethod1()=0 ;
    > > virtual void virtualMethod2()=0 ;
    > > virtual void virtualMethod3()=0 ;
    > > } ;

    >
    > This has absolutely no value. Those functions are accesible anyway, you
    > know.
    >
    > >
    > >
    > > I did the above considering the facts that
    > > - in any case, the virtual functions will always be called through
    > > the base class pointer only
    > > - No. of public virtual interfaces should be reduced as much as
    > > possible
    > >
    > > Here are my questions:
    > > 1)
    > > Can I consider this as a good design? If yes/no, why?

    >
    > No - because you do not reduce the number of public, virtual functions.
    > >
    > > 2)
    > > How about
    > > class derived : private base
    > > {
    > >
    > > }
    > > instead of the above design, as anyway, all the inherited virtual
    > > functions need to be made as private ?
    > >
    > > Is this a correct design? If yes/no, why?

    >
    > This is not any better as base *b = new derived(...) will no longer

    compile.
    >
    > >
    > >
    > > 3)
    > > What are the flaws in the above design and what do you suggest for
    > > improvements?

    >
    > Use this scheme instead:
    > class base
    > {
    > // other members
    > virtual void virtualMethod1()=0 ;
    > virtual void virtualMethod2()=0 ;
    > virtual void virtualMethod3()=0 ;
    > public:
    > virtual ~base()
    > {
    > }
    > void method1() { virtualMethod1();}
    > void method2() { virtualMethod2();}
    > void method3() { virtualMethod3();}
    >
    > };
    >
    >
    >
     
    Joe, Jan 31, 2004
    #4
  5. qazmlp

    Phlip Guest

    Joe wrote:

    > Just curious......what is the advantage of lowering the number of public
    > virtual methods? Thanks


    Liskov Substitution Principle gets easier to enforce - admitedly by
    attrition, not necessarily thinking.

    --
    Phlip
    http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces
     
    Phlip, Jan 31, 2004
    #5
  6. qazmlp

    Rob Guest

    "Joe" <> wrote in message
    news:UXVSb.16547$...
    > Just curious......what is the advantage of lowering the number of public
    > virtual methods? Thanks
    >


    The most usual reason is that a public virtual function (virtually by
    definition :)
    can be called by anyone, and the developer who overrides it must
    therefore do things such as checking arguments to make sure they
    are valid, and that the affected object remains in a valid state. And it
    is easier to make a mistake and forget to check something.

    Private virtual functions do not have that problem. They can only be
    called by member functions or friends of the base class. This means
    that the implementer of the base class can control the conditions under
    which the virtual function is called. In this way, necessary preconditions
    and postconditions can be checked and/or enforced.
     
    Rob, Feb 1, 2004
    #6
  7. qazmlp

    Rod Davison Guest

    On Sat, 31 Jan 2004 07:08:44 -0800, qazmlp wrote:

    > class base
    > {
    > // other members
    > public:
    > virtual ~base()
    > {
    > }
    > virtual void virtualMethod1()=0 ;
    > virtual void virtualMethod2()=0 ;
    > virtual void virtualMethod3()=0 ;
    > } ;
    >
    >
    > I derive a class from base. I want to make all the virtual functions as
    > private.



    Aside from not being allowed in some OO languages, it is always a bad
    design decision to have a derived class remove an operation from the base
    class definition, which is essentially what making a base class public
    operation private in the derived class. Two reasons:

    1. The derived class should not break the base class contract -- which is
    what Liskov's principle is all about.

    2. Derived classes should extend base classes, not reduce them -- this
    suggests a potential design problem with the inheritance hierarchy.

    Practical quick fix (but not necessarily a good one). Make the base class
    virtual methods protected.

    Also from a practical point of view, if your code compiles, are you really
    sure that it does what think it does?

    --
    ..................................................
    The three most dangerous things are a programmer
    with a soldering iron, a manager who codes, and a user who gets ideas.

    Rod Davison - Critical Knowledge Systems Inc.
     
    Rod Davison, Feb 1, 2004
    #7
  8. qazmlp

    Rod Davison Guest


    > Also from a practical point of view, if your code compiles, are you really
    > sure that it does what think it does?


    Looking at the code I suspect that there will be a problem with the vtab
    setup.
    --
    ..................................................
    If you lend someone $20, and never see that person
    again, it was probably worth it.

    Rod Davison - Critical Knowledge Systems Inc.
     
    Rod Davison, Feb 1, 2004
    #8
  9. qazmlp

    Daniel T. Guest

    (qazmlp) wrote:

    > class base
    > {
    > // other members
    > public:
    > virtual ~base()
    > {
    > }
    > virtual void virtualMethod1()=0 ;
    > virtual void virtualMethod2()=0 ;
    > virtual void virtualMethod3()=0 ;
    > } ;
    >
    >
    > I derive a class from base. I want to make all the virtual functions
    > as private.
    > class derived : public base
    > {
    > // other members
    > public:
    > virtual ~derived()
    > {
    > }
    >
    > void myPublicInterface1() ;
    > void myPublicInterface1() ;
    >
    > private:
    > virtual void virtualMethod1()=0 ;
    > virtual void virtualMethod2()=0 ;
    > virtual void virtualMethod3()=0 ;
    > } ;
    >
    >
    > I did the above considering the facts that
    > - in any case, the virtual functions will always be called through
    > the base class pointer only


    Is this true? Will it always be true? Let's say I have a function with a
    derived* and I want to call virtualMaethod1.

    void func( derived* d ) {
    static_cast<base*>(d)->virtualMethod1();
    }

    It can be done, by why are you forcing the client to jump through the
    extra hoop?


    > - No. of public virtual interfaces should be reduced as much as
    > possible


    You haven't reduced the number of virtual interfaces in 'derived' with
    the above code.


    > Here are my questions:
    > 1)
    > Can I consider this as a good design? If yes/no, why?


    No, for the reasons cited above.


    > 2)
    > How about
    > class derived : private base
    > {
    >
    > }
    > instead of the above design, as anyway, all the inherited virtual
    > functions need to be made as private ?
    >
    > Is this a correct design? If yes/no, why?


    If you do this, you can't hold a derived object in a base*. Is that what
    you want?

    > 3)
    > What are the flaws in the above design and what do you suggest for
    > improvements?


    I see two flaws in the above design. (a) you are attempting to make
    private in derived that which cannot be made private because it is
    public in the base class. (b) I don't know what in in 'other members' in
    your base class, but I suspect I would not approve of whatever it is...
     
    Daniel T., Feb 1, 2004
    #9
  10. (qazmlp) might (or might not) have written
    this on (or about) 31 Jan 2004 07:08:44 -0800, :

    >class base
    >{
    > // other members
    > public:
    > virtual ~base()
    > {
    > }
    > virtual void virtualMethod1()=0 ;
    > virtual void virtualMethod2()=0 ;
    > virtual void virtualMethod3()=0 ;
    >} ;
    >
    >
    >I derive a class from base. I want to make all the virtual functions
    >as private.
    >class derived : public base
    >{
    > // other members
    > public:
    > virtual ~derived()
    > {
    > }
    >
    > void myPublicInterface1() ;
    > void myPublicInterface1() ;
    >
    > private:
    > virtual void virtualMethod1()=0 ;
    > virtual void virtualMethod2()=0 ;
    > virtual void virtualMethod3()=0 ;
    >} ;
    >
    >
    >I did the above considering the facts that
    > - in any case, the virtual functions will always be called through
    >the base class pointer only
    > - No. of public virtual interfaces should be reduced as much as
    >possible
    >
    >Here are my questions:
    >1)
    >Can I consider this as a good design? If yes/no, why?


    No, probably because it won't compile. You can't make a derivative
    member less accessible than a base member.
    >
    >2)
    >How about
    >class derived : private base
    >{
    >
    >}
    >instead of the above design, as anyway, all the inherited virtual
    >functions need to be made as private ?
    >
    >Is this a correct design? If yes/no, why?


    This is better if the intent is for all the methods of derived to be
    inaccessible to users of derived. However you also have to remember
    that private inheritance prevents the implicit upcast from derived* to
    base*

    >3)
    >What are the flaws in the above design and what do you suggest for
    >improvements?


    That depends on your intent. I think 2) is better than 1).



    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
     
    Uncle Bob (Robert C. Martin), Feb 2, 2004
    #10
  11. "Uncle Bob (Robert C. Martin)" <> skrev i
    meddelandet news:...

    > 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
     
    Dag Henriksson, Feb 3, 2004
    #11
  12. "Dag Henriksson" <> might (or might not)
    have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :

    >"Uncle Bob (Robert C. Martin)" <> skrev i
    >meddelandet news:...
    >
    >> 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
     
    Uncle Bob (Robert C. Martin), Feb 3, 2004
    #12
  13. qazmlp

    Rod Davison Guest

    On Tue, 03 Feb 2004 09:43:19 +0100, Dag Henriksson wrote:

    > "Uncle Bob (Robert C. Martin)" <> skrev
    > i meddelandet news:...
    >
    >> 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.
     
    Rod Davison, Feb 3, 2004
    #13
  14. "Uncle Bob (Robert C. Martin)" <> skrev i
    meddelandet news:...
    > "Dag Henriksson" <> might (or might not)
    > have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :
    >
    > >"Uncle Bob (Robert C. Martin)" <> skrev i
    > >meddelandet news:...
    > >
    > >> 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
     
    Dag Henriksson, Feb 3, 2004
    #14
  15. "Rod Davison" <> 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
     
    Dag Henriksson, Feb 3, 2004
    #15
  16. qazmlp

    Avner Ben Guest

    Re: Should 'public virtual' always become 'private virtual'? & usingprivate inheritance

    Uncle Bob (Robert C. Martin) wrote:
    > "Dag Henriksson" <> 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.
     
    Avner Ben, Feb 3, 2004
    #16
  17. 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
     
    Tsolak Petrosian, Feb 3, 2004
    #17
  18. "Uncle Bob (Robert C. Martin)" <> wrote in
    message news:...
    > "Dag Henriksson" <> might (or might not)
    > have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :
    >
    > >"Uncle Bob (Robert C. Martin)" <> skrev i
    > >meddelandet news:...
    > >
    > >> 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
     
    Nick Hounsome, Feb 3, 2004
    #18
  19. On Tue, 3 Feb 2004 15:10:50 +0100, "Dag Henriksson"
    <> wrote:

    >"Uncle Bob (Robert C. Martin)" <> skrev i
    >meddelandet news:...
    >> "Dag Henriksson" <> might (or might not)
    >> have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :
    >>
    >> >"Uncle Bob (Robert C. Martin)" <> skrev i
    >> >meddelandet news:...
    >> >
    >> >> 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.
     
    Robert C. Martin, Feb 4, 2004
    #19
  20. qazmlp

    Daniel T. Guest

    In article <>,
    Robert C. Martin <> wrote:

    > On Tue, 3 Feb 2004 15:10:50 +0100, "Dag Henriksson"
    > <> wrote:
    >
    > >"Uncle Bob (Robert C. Martin)" <> skrev i
    > >meddelandet news:...
    > >> "Dag Henriksson" <> might (or might not)
    > >> have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :
    > >>
    > >> >"Uncle Bob (Robert C. Martin)" <> skrev i
    > >> >meddelandet news:...
    > >> >
    > >> >> 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++.
     
    Daniel T., Feb 4, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Charles A. Lackman
    Replies:
    1
    Views:
    1,409
    smith
    Dec 8, 2004
  2. SpamProof
    Replies:
    0
    Views:
    607
    SpamProof
    Oct 21, 2003
  3. DaveLessnau
    Replies:
    3
    Views:
    438
    Howard
    May 16, 2005
  4. Mr Flibble
    Replies:
    0
    Views:
    318
    Mr Flibble
    Jun 6, 2006
  5. Stéphane Ninin

    private inheritance and public members

    Stéphane Ninin, Jun 7, 2006, in forum: C++
    Replies:
    1
    Views:
    319
    Victor Bazarov
    Jun 7, 2006
Loading...

Share This Page