Redudant virtual keyword?

[Daniel Kay]

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

 

[Victor Bazarov]

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

 

[Howard]

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

 

[Mike Wahler]

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

 

[Greg Comeau]

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.

 

[Daniel Kay]

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

 

[Mike Wahler]

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

 

[Markus Moll]

Hi

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

 

[Greg Comeau]

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.

 

[Howard]

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

 

[Greg Comeau]

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.

 

[Howard]

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

 

[Greg Comeau]

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.