Redudant virtual keyword?

Discussion in 'C++' started by Daniel Kay, Oct 11, 2005.

  1. Daniel Kay

    Daniel Kay Guest

    Hi Folks!

    Everytime I work with virtual and pure virtual methods I ask myself if
    there is a difference between class B and class C (see below). Is it
    redundant to repeat the virtual keyword in a derived class? Or is there
    any difference I need to consider? I have seen both ways when I read
    source code from external sources. So far I didn't find any answers in
    my books or on the net.

    class A {
    public:
    virtual void foo() = 0;
    virtual void bar() {}
    };

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

    class C {
    public:
    virtual void foo() {}
    virtual void bar() {}
    };

    CU,
    Daniel Kay
     
    Daniel Kay, Oct 11, 2005
    #1
    1. Advertising

  2. Daniel Kay wrote:
    > Everytime I work with virtual and pure virtual methods I ask myself if
    > there is a difference between class B and class C (see below). Is it
    > redundant to repeat the virtual keyword in a derived class?


    From the language point of view, yes. From a team development process
    point of view, no. It's a style thing.

    > [...]


    V
     
    Victor Bazarov, Oct 11, 2005
    #2
    1. Advertising

  3. Daniel Kay

    Howard Guest

    "Daniel Kay" <> wrote in message
    news:434bfc5a$0$10242$-online.net...
    > Hi Folks!
    >
    > Everytime I work with virtual and pure virtual methods I ask myself if
    > there is a difference between class B and class C (see below). Is it
    > redundant to repeat the virtual keyword in a derived class? Or is there
    > any difference I need to consider? I have seen both ways when I read
    > source code from external sources. So far I didn't find any answers in my
    > books or on the net.
    >
    > class A {
    > public:
    > virtual void foo() = 0;
    > virtual void bar() {}
    > };
    >
    > class B {
    > public:
    > void foo() {}
    > void bar() {}
    > };
    >


    From your question, I assume you meant:

    class B : public A {

    > class C {
    > public:
    > virtual void foo() {}
    > virtual void bar() {}
    > };
    >


    And likewise here:

    class C : public B { // or : public A

    Correct?

    If so, then the virtual keyword is indeed redundant, in that it is not
    needed in the derived class definitions. Once declared virtual in a base
    class, it remains virtual in derived classes, whether or not you include the
    virtual keyword.

    As a standard practice, though, I always repeat the keyword in derived
    classes, just so that I KNOW it's a virtual method, and don't have to look
    back through my base classes to see if it's declared virtual somewhere.
    (Besides, I usually copy & paste the function declarations into my derived
    class anyway, so the virtual keyword gets copied right along with the rest
    of the function declaration.)

    -Howard
     
    Howard, Oct 11, 2005
    #3
  4. Daniel Kay

    Mike Wahler Guest

    "Daniel Kay" <> wrote in message
    news:434bfc5a$0$10242$-online.net...
    > Hi Folks!
    >
    > Everytime I work with virtual and pure virtual methods I ask myself if
    > there is a difference between class B and class C (see below). Is it
    > redundant to repeat the virtual keyword in a derived class?


    Yes, but it's often done in the interest of clarity.

    > Or is there any difference I need to consider?


    No operational difference.

    > I have seen both ways when I read source code from external sources. So
    > far I didn't find any answers in my books or on the net.


    Which books? Perhaps you need better ones.

    -Mike
     
    Mike Wahler, Oct 11, 2005
    #4
  5. Daniel Kay

    Greg Comeau Guest

    In article <434bfc5a$0$10242$-online.net>,
    Daniel Kay <> wrote:
    >Everytime I work with virtual and pure virtual methods I ask myself if
    >there is a difference between class B and class C (see below). Is it
    >redundant to repeat the virtual keyword in a derived class? Or is there
    >any difference I need to consider? I have seen both ways when I read
    >source code from external sources. So far I didn't find any answers in
    >my books or on the net.
    >
    >class A {
    >public:
    > virtual void foo() = 0;
    > virtual void bar() {}
    >};
    >
    >class B {
    >public:
    > void foo() {}
    > void bar() {}
    >};
    >
    >class C {
    >public:
    > virtual void foo() {}
    > virtual void bar() {}
    >};


    Think you left something out:
    Did you intend that B and C inherit from A?
    Anyway, virtual's inherit as virtual, so whether you
    utter the virtual keywork again is up to you.
    --
    Greg Comeau / Celebrating 20 years of Comeauity!
    Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
    World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
    Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
     
    Greg Comeau, Oct 11, 2005
    #5
  6. Daniel Kay

    Daniel Kay Guest

    Mike Wahler wrote:

    >>I have seen both ways when I read source code from external sources. So
    >>far I didn't find any answers in my books or on the net.

    >
    >
    > Which books? Perhaps you need better ones.


    Hey Mike!

    The C++ Programming language 4. Edition (German). So far I thought this
    was the bible. Maybe I am just blind. :)

    Anyway, THX anyone...

    CU,
    Daniel Kay
     
    Daniel Kay, Oct 11, 2005
    #6
  7. Daniel Kay

    Mike Wahler Guest

    "Daniel Kay" <> wrote in message
    news:434c00d5$0$24159$-online.net...
    > Mike Wahler wrote:
    >
    >>>I have seen both ways when I read source code from external sources. So
    >>>far I didn't find any answers in my books or on the net.

    >>
    >>
    >> Which books? Perhaps you need better ones.

    >
    > Hey Mike!
    >
    > The C++ Programming language 4. Edition (German). So far I thought this
    > was the bible.


    It is a very good book. But the authoritative reference
    (i.e. the 'bible') would be the ISO standard defining the
    language (ISO 14882).

    > Maybe I am just blind. :)


    I don't know. I have the third edition, but I don't remember
    if this particular issue is directly addressed there. I do
    remember reading about it in *some* of my (many) C++ books.

    -Mike
     
    Mike Wahler, Oct 11, 2005
    #7
  8. Daniel Kay

    Markus Moll Guest

    Hi

    Daniel Kay wrote:

    > The C++ Programming language 4. Edition (German). So far I thought this
    > was the bible. Maybe I am just blind. :)


    It's mentioned implicitly on page 329 (look at the "Angestellter/Manager"
    example, then read the last paragraph on the page, it says any function
    with the same name and the same set of parameter types overwrites the
    virtual function in the base class)

    Markus
     
    Markus Moll, Oct 11, 2005
    #8
  9. Daniel Kay

    Greg Comeau Guest

    In article <59T2f.412714$>,
    Howard <> wrote:
    >As a standard practice, though, I always repeat [virtual] in derived
    >classes, just so that I KNOW it's a virtual method, and don't have to look
    >back through my base classes to see if it's declared virtual somewhere.
    >(Besides, I usually copy & paste the function declarations into my derived
    >class anyway, so the virtual keyword gets copied right along with the rest
    >of the function declaration.)


    I buy this up to a point, however, such a dependency can be
    (1) a false sense of security and (2) someitme outright wrong
    at least as I understand what you wrote.
    --
    Greg Comeau / Celebrating 20 years of Comeauity!
    Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
    World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
    Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
     
    Greg Comeau, Oct 11, 2005
    #9
  10. Daniel Kay

    Howard Guest

    "Greg Comeau" <> wrote in message
    news:dih6k8$332$...
    > In article <59T2f.412714$>,
    > Howard <> wrote:
    >>As a standard practice, though, I always repeat [virtual] in derived
    >>classes, just so that I KNOW it's a virtual method, and don't have to look
    >>back through my base classes to see if it's declared virtual somewhere.
    >>(Besides, I usually copy & paste the function declarations into my derived
    >>class anyway, so the virtual keyword gets copied right along with the rest
    >>of the function declaration.)

    >
    > I buy this up to a point, however, such a dependency can be
    > (1) a false sense of security and (2) someitme outright wrong
    > at least as I understand what you wrote.
    > --


    I don't get you. What's wrong with my approach? Where might it cause me
    trouble to always include the virtual keyword for methods in derived classes
    when the virtual keyword is specified for the base class function(s) being
    overridden?

    The only "false sense of security" might be if I were to assume that any
    function which does not have the virtual keyword must NOT be virtual. I
    never implied I would do that. I said I would know it WAS virtual by its
    presence, not the other way around. If I do NOT see the virtual keyword,
    then I have to look back through any base classes to see if perhaps it IS
    actually virtual. (Thus, always repeating the virtual keyword for
    overriding methods saves me the time I would otherwise need to look it up.)

    -Howard
     
    Howard, Oct 11, 2005
    #10
  11. Daniel Kay

    Greg Comeau Guest

    In article <weV2f.413332$>,
    Howard <> wrote:
    >
    >"Greg Comeau" <> wrote in message
    >news:dih6k8$332$...
    >> In article <59T2f.412714$>,
    >> Howard <> wrote:
    >>>As a standard practice, though, I always repeat [virtual] in derived
    >>>classes, just so that I KNOW it's a virtual method, and don't have to look
    >>>back through my base classes to see if it's declared virtual somewhere.
    >>>(Besides, I usually copy & paste the function declarations into my derived
    >>>class anyway, so the virtual keyword gets copied right along with the rest
    >>>of the function declaration.)

    >>
    >> I buy this up to a point, however, such a dependency can be
    >> (1) a false sense of security and (2) someitme outright wrong
    >> at least as I understand what you wrote.
    >> --

    >
    >I don't get you. What's wrong with my approach? Where might it cause me
    >trouble to always include the virtual keyword for methods in derived classes
    >when the virtual keyword is specified for the base class function(s) being
    >overridden?
    >
    >The only "false sense of security" might be if I were to assume that any
    >function which does not have the virtual keyword must NOT be virtual. I
    >never implied I would do that. I said I would know it WAS virtual by its
    >presence, not the other way around. If I do NOT see the virtual keyword,
    >then I have to look back through any base classes to see if perhaps it IS
    >actually virtual. (Thus, always repeating the virtual keyword for
    >overriding methods saves me the time I would otherwise need to look it up.)


    Somebody (not necessarily you) may for instance have:

    struct xyz {
    void foo();
    };

    struct abc : xyz {
    virtual void foo();
    };

    Seeing foo is virtual in abc says nothing of it in xyz.
    --
    Greg Comeau / Celebrating 20 years of Comeauity!
    Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
    World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
    Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
     
    Greg Comeau, Oct 11, 2005
    #11
  12. Daniel Kay

    Howard Guest

    "Greg Comeau" <> wrote in message
    news:dihaab$fhv$...
    > In article <weV2f.413332$>,
    > Howard <> wrote:
    >>
    >>"Greg Comeau" <> wrote in message
    >>news:dih6k8$332$...
    >>> In article <59T2f.412714$>,
    >>> Howard <> wrote:
    >>>>As a standard practice, though, I always repeat [virtual] in derived
    >>>>classes, just so that I KNOW it's a virtual method, and don't have to
    >>>>look
    >>>>back through my base classes to see if it's declared virtual somewhere.
    >>>>(Besides, I usually copy & paste the function declarations into my
    >>>>derived
    >>>>class anyway, so the virtual keyword gets copied right along with the
    >>>>rest
    >>>>of the function declaration.)
    >>>
    >>> I buy this up to a point, however, such a dependency can be
    >>> (1) a false sense of security and (2) someitme outright wrong
    >>> at least as I understand what you wrote.
    >>> --

    >>
    >>I don't get you. What's wrong with my approach? Where might it cause me
    >>trouble to always include the virtual keyword for methods in derived
    >>classes
    >>when the virtual keyword is specified for the base class function(s) being
    >>overridden?
    >>
    >>The only "false sense of security" might be if I were to assume that any
    >>function which does not have the virtual keyword must NOT be virtual. I
    >>never implied I would do that. I said I would know it WAS virtual by its
    >>presence, not the other way around. If I do NOT see the virtual keyword,
    >>then I have to look back through any base classes to see if perhaps it IS
    >>actually virtual. (Thus, always repeating the virtual keyword for
    >>overriding methods saves me the time I would otherwise need to look it
    >>up.)

    >
    > Somebody (not necessarily you) may for instance have:
    >
    > struct xyz {
    > void foo();
    > };
    >
    > struct abc : xyz {
    > virtual void foo();
    > };
    >
    > Seeing foo is virtual in abc says nothing of it in xyz.
    > --


    I think my compiler issues a warning if I do that, saying that a virtual
    function is hiding a non-virtual function in the base class.

    In any case, I take it your point is that if I see the virtual keyword in
    abc above, then I still have to be careful about any assumptions I make
    about whether it's virtual in the base class or not. Point taken. I still
    think it's good practice, even if it's not a foolproof guarantee. (There
    are always bigger fools...)

    -Howard
     
    Howard, Oct 12, 2005
    #12
  13. Daniel Kay

    Greg Comeau Guest

    In article <Yi93f.417919$>,
    Howard <> wrote:
    >"Greg Comeau" <> wrote in message
    >news:dihaab$fhv$...
    >> In article <weV2f.413332$>,
    >> Howard <> wrote:
    >>>
    >>>"Greg Comeau" <> wrote in message
    >>>news:dih6k8$332$...
    >>>> In article <59T2f.412714$>,
    >>>> Howard <> wrote:
    >>>>>As a standard practice, though, I always repeat [virtual] in derived
    >>>>>classes, just so that I KNOW it's a virtual method, and don't have to
    >>>>>look
    >>>>>back through my base classes to see if it's declared virtual somewhere.
    >>>>>(Besides, I usually copy & paste the function declarations into my
    >>>>>derived
    >>>>>class anyway, so the virtual keyword gets copied right along with the
    >>>>>rest
    >>>>>of the function declaration.)
    >>>>
    >>>> I buy this up to a point, however, such a dependency can be
    >>>> (1) a false sense of security and (2) someitme outright wrong
    >>>> at least as I understand what you wrote.
    >>>> --
    >>>
    >>>I don't get you. What's wrong with my approach? Where might it cause me
    >>>trouble to always include the virtual keyword for methods in derived
    >>>classes
    >>>when the virtual keyword is specified for the base class function(s) being
    >>>overridden?
    >>>
    >>>The only "false sense of security" might be if I were to assume that any
    >>>function which does not have the virtual keyword must NOT be virtual. I
    >>>never implied I would do that. I said I would know it WAS virtual by its
    >>>presence, not the other way around. If I do NOT see the virtual keyword,
    >>>then I have to look back through any base classes to see if perhaps it IS
    >>>actually virtual. (Thus, always repeating the virtual keyword for
    >>>overriding methods saves me the time I would otherwise need to look it
    >>>up.)

    >>
    >> Somebody (not necessarily you) may for instance have:
    >>
    >> struct xyz {
    >> void foo();
    >> };
    >>
    >> struct abc : xyz {
    >> virtual void foo();
    >> };
    >>
    >> Seeing foo is virtual in abc says nothing of it in xyz.
    >> --

    >
    >I think my compiler issues a warning if I do that, saying that a virtual
    >function is hiding a non-virtual function in the base class.
    >
    >In any case, I take it your point is that if I see the virtual keyword in
    >abc above, then I still have to be careful about any assumptions I make
    >about whether it's virtual in the base class or not. Point taken.


    My point is to not make any assumptions, but indeed instead to do
    the careful inspection, etc.

    >I still
    >think it's good practice, even if it's not a foolproof guarantee. (There
    >are always bigger fools...)


    Not only is it not foolproof, it's not even expert proof.
    --
    Greg Comeau / Celebrating 20 years of Comeauity!
    Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
    World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
    Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
     
    Greg Comeau, Oct 12, 2005
    #13
    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. Dhruba Bandopadhyay

    ASP VIRTUAL keyword not working in ASP.NET anymore :S

    Dhruba Bandopadhyay, Mar 22, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    4,963
    Dhruba Bandopadhyay
    Mar 22, 2006
  2. Shao Zhang
    Replies:
    24
    Views:
    829
    jeffc
    Jul 21, 2004
  3. Michael P. O'Connor

    the virtual keyword

    Michael P. O'Connor, Mar 5, 2005, in forum: C++
    Replies:
    16
    Views:
    2,735
    Matthias Kaeppler
    Mar 6, 2005
  4. Replies:
    6
    Views:
    490
    Peter Otten
    May 10, 2007
  5. Hamilton, William

    RE: keyword checker - keyword.kwlist

    Hamilton, William, May 10, 2007, in forum: Python
    Replies:
    4
    Views:
    378
Loading...

Share This Page