Redudant virtual keyword?

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

re: Redudant virtual keyword?

"Daniel Kay" <daniel_kay@arcor.de> wrote in message
news:434bfc5a$0$10242$9b4e6d93@newsread2.arcor-online.net...[color=blue]
> 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() {}
> };
>[/color]

From your question, I assume you meant:

class B : public A {
[color=blue]
> class C {
> public:
> virtual void foo() {}
> virtual void bar() {}
> };
>[/color]

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

re: Redudant virtual keyword?

Daniel Kay wrote:[color=blue]
> 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?[/color]

From the language point of view, yes. From a team development process
point of view, no. It's a style thing.
[color=blue]
> [...][/color]

V

re: Redudant virtual keyword?

"Daniel Kay" <daniel_kay@arcor.de> wrote in message
news:434bfc5a$0$10242$9b4e6d93@newsread2.arcor-online.net...[color=blue]
> 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?[/color]

Yes, but it's often done in the interest of clarity.
[color=blue]
> Or is there any difference I need to consider?[/color]

No operational difference.
[color=blue]
> 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.[/color]

Which books? Perhaps you need better ones.

-Mike

re: Redudant virtual keyword?

In article <434bfc5a$0$10242$9b4e6d93@newsread2.arcor-online.net>,
Daniel Kay <daniel_kay@arcor.de> wrote:[color=blue]
>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() {}
>};[/color]

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?

re: Redudant virtual keyword?

Mike Wahler wrote:
[color=blue][color=green]
>>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.[/color]
>
>
> Which books? Perhaps you need better ones.[/color]

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

re: Redudant virtual keyword?

"Daniel Kay" <daniel_kay@arcor.de> wrote in message
news:434c00d5$0$24159$9b4e6d93@newsread4.arcor-online.net...[color=blue]
> Mike Wahler wrote:
>[color=green][color=darkred]
>>>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.[/color]
>>
>>
>> Which books? Perhaps you need better ones.[/color]
>
> Hey Mike!
>
> The C++ Programming language 4. Edition (German). So far I thought this
> was the bible.[/color]

It is a very good book. But the authoritative reference
(i.e. the 'bible') would be the ISO standard defining the
language (ISO 14882).
[color=blue]
> Maybe I am just blind. :-)[/color]

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

re: Redudant virtual keyword?

Hi

Daniel Kay wrote:
[color=blue]
> The C++ Programming language 4. Edition (German). So far I thought this
> was the bible. Maybe I am just blind. :-)[/color]

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

re: Redudant virtual keyword?

In article <59T2f.412714$5N3.216579@bgtnsc05-news.ops.worldnet.att.net>,
Howard <alicebt@hotmail.com> wrote:[color=blue]
>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.)[/color]

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?

re: Redudant virtual keyword?

"Greg Comeau" <comeau@panix.com> wrote in message
news:dih6k8$332$1@panix2.panix.com...[color=blue]
> In article <59T2f.412714$5N3.216579@bgtnsc05-news.ops.worldnet.att.net>,
> Howard <alicebt@hotmail.com> wrote:[color=green]
>>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.)[/color]
>
> 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.
> --[/color]

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

re: Redudant virtual keyword?

In article <weV2f.413332$5N3.277561@bgtnsc05-news.ops.worldnet.att.net>,
Howard <alicebt@hotmail.com> wrote:[color=blue]
>
>"Greg Comeau" <comeau@panix.com> wrote in message
>news:dih6k8$332$1@panix2.panix.com...[color=green]
>> In article <59T2f.412714$5N3.216579@bgtnsc05-news.ops.worldnet.att.net>,
>> Howard <alicebt@hotmail.com> wrote:[color=darkred]
>>>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.)[/color]
>>
>> 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.
>> --[/color]
>
>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.)[/color]

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?

re: Redudant virtual keyword?

"Greg Comeau" <comeau@panix.com> wrote in message
news:dihaab$fhv$1@panix2.panix.com...[color=blue]
> In article <weV2f.413332$5N3.277561@bgtnsc05-news.ops.worldnet.att.net>,
> Howard <alicebt@hotmail.com> wrote:[color=green]
>>
>>"Greg Comeau" <comeau@panix.com> wrote in message
>>news:dih6k8$332$1@panix2.panix.com...[color=darkred]
>>> In article <59T2f.412714$5N3.216579@bgtnsc05-news.ops.worldnet.att.net>,
>>> Howard <alicebt@hotmail.com> 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.
>>> --[/color]
>>
>>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.)[/color]
>
> 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.
> --[/color]

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

re: Redudant virtual keyword?

In article <Yi93f.417919$5N3.307781@bgtnsc05-news.ops.worldnet.att.net>,
Howard <alicebt@hotmail.com> wrote:[color=blue]
>"Greg Comeau" <comeau@panix.com> wrote in message
>news:dihaab$fhv$1@panix2.panix.com...[color=green]
>> In article <weV2f.413332$5N3.277561@bgtnsc05-news.ops.worldnet.att.net>,
>> Howard <alicebt@hotmail.com> wrote:[color=darkred]
>>>
>>>"Greg Comeau" <comeau@panix.com> wrote in message
>>>news:dih6k8$332$1@panix2.panix.com...
>>>> In article <59T2f.412714$5N3.216579@bgtnsc05-news.ops.worldnet.att.net>,
>>>> Howard <alicebt@hotmail.com> 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.)[/color]
>>
>> 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.
>> --[/color]
>
>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.[/color]

My point is to not make any assumptions, but indeed instead to do
the careful inspection, etc.
[color=blue]
>I still
>think it's good practice, even if it's not a foolproof guarantee. (There
>are always bigger fools...)[/color]

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?