Changing access scope of virtual functions

Discussion in 'C++' started by Kira Yamato, Jan 21, 2008.

  1. Kira Yamato

    Kira Yamato Guest

    Two questions concerning overriding virtual functions. First question
    should have a clear answer, while the second question is more of an
    opinion question.


    1) Does the C++ standard say anything regarding changing the access
    scope when overriding virtual functions?

    For example:

    class A { protected: virtual void foo(); };
    class B : public A { public: virtual void foo(); };
    class C : public A { private: virtual void foo(); };

    I've tested that in g++ 4.0.1 the compiler does not complain at all.
    But that just may be an implementation thing.

    Of course, I am aware of private and protected inheritance, which will
    implicitly demote the access scope of every base methods in the derived
    class. So, I would think that demote access scope has a well-defined
    behavior in the C++ standard.

    But what about promoting access scope? Is it ever a dangerous thing to do?


    2) From a software design perspective, is it ever a good idea to
    promote or demote the access scope of a virtual function? Or is it
    like one of those "permissible but not beneficial" features of C++?

    In java, you can only promote access scope, i.e., you cannot decrease
    the accessibility of a method in the derived class that overrides one
    in the base class. Of course, that is only because of the way java's
    security model works.


    Thanks for any input.

    --

    -kira
     
    Kira Yamato, Jan 21, 2008
    #1
    1. Advertising

  2. Kira Yamato

    James Kanze Guest

    On Jan 22, 12:38 am, Kira Yamato wrote:
    > Two questions concerning overriding virtual functions. First
    > question should have a clear answer, while the second question
    > is more of an opinion question.


    > 1) Does the C++ standard say anything regarding changing the
    > access scope when overriding virtual functions?


    No. Access is a property of the class interface, and depends
    only on the static type. A derived class is free to define
    whatever interface it wants, including whatever access it cares
    to grant. (And it's not access scope, but simply access, or
    access rights. It has absolutely nothing to do with scope.)

    > For example:


    > class A { protected: virtual void foo(); };
    > class B : public A { public: virtual void foo(); };
    > class C : public A { private: virtual void foo(); };


    > I've tested that in g++ 4.0.1 the compiler does not complain at all.
    > But that just may be an implementation thing.


    > Of course, I am aware of private and protected inheritance, which will
    > implicitly demote the access scope of every base methods in the derived
    > class. So, I would think that demote access scope has a well-defined
    > behavior in the C++ standard.


    The access specifiers on inheritance have a somewhat different
    role; inheriting privately means that a user cannot use an
    object of derived type as a base. (In particular, the implicit
    derived to base conversions are disactivated.)

    > But what about promoting access scope? Is it ever a dangerous
    > thing to do?


    The derived class is free to define its own contracts, including
    making functions available which weren't available in the base
    class. Whether it is a good idea or not is another question.

    > 2) From a software design perspective, is it ever a good idea to
    > promote or demote the access scope of a virtual function?


    Most of the time, all of the virtual functions will be private,
    and should probably remain that way throughout the hierarchy.
    There are exceptions, however.

    > Or is it like one of those "permissible but not beneficial"
    > features of C++?


    There are doubtlessly cases where increasing access is
    reasonable (i.e. private in the base class, but public in the
    derived). Reducing access seems less useful (unless the
    inheritance is private to begin with). But there doesn't seem
    to be any valid reason to ban it, either, and the general
    principle of C++ is to not ban anything without a very good
    reason.

    > In java, you can only promote access scope, i.e., you cannot
    > decrease the accessibility of a method in the derived class
    > that overrides one in the base class. Of course, that is only
    > because of the way java's security model works.


    The logic, here, of course, is that the more limited access is
    only apparent---you can always access the function by converting
    your pointer to a pointer to base. I think some C++ compilers
    warn in this case as well. On the other hand, if you inherit
    privately, it often makes good sense to restrict the access more
    in the derived class.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jan 22, 2008
    #2
    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. Michael Winter
    Replies:
    9
    Views:
    643
    Michael Winter
    Sep 24, 2003
  2. heted7
    Replies:
    33
    Views:
    1,078
    Chris Dearlove
    May 12, 2005
  3. Replies:
    3
    Views:
    396
    Nitin Motgi
    Jan 31, 2006
  4. Replies:
    7
    Views:
    395
    Richard
    Aug 28, 2006
  5. John Goche
    Replies:
    10
    Views:
    797
    Marcus Kwok
    Dec 8, 2006
Loading...

Share This Page