virtual question

[Thomas]

hi all,
i have 2 classes and a virtual function:


class BaseClass
{ public:
virtual void somefunction();
};

class DerivedClass : public BaseClass
{ public:
/*virtual*/ void somefunction();
};

This seems to work even when I drop the 'virtual' keyword in the derived
class. Does this make any difference? Or is the second 'virtual' in the
derived class obsolete?

Thanks,
Thomas

 

[stefan.ciobaca]

There isn't any difference, in the sense that both are legal and
mean the same thing. On the other hand, a programmer looking
at the DerivedClass will have to wonder wether somefunction is
virtual or not. A bit of a nuissance when dealing with C++ code.

 

[Dennis Jones]

hi all,
i have 2 classes and a virtual function:


class BaseClass
{ public:
virtual void somefunction();
};

class DerivedClass : public BaseClass
{ public:
/*virtual*/ void somefunction();
};

This seems to work even when I drop the 'virtual' keyword in the derived
class. Does this make any difference? Or is the second 'virtual' in the
derived class obsolete?

"Obsolete" isn't the word I would use. Remember this: "once virtual, always
virtual." Therefore, while the use of "virtual" in derived classes is
allowed, it is redundant and unnecessary.

- Dennis

 

[Dennis Jones]

"Obsolete" isn't the word I would use. Remember this: "once virtual, always
virtual." Therefore, while the use of "virtual" in derived classes is
allowed, it is redundant and unnecessary.

Oh, I should point out that while including "virtual" in derived classes
does no harm, it certainly makes it clear that the function is virtual.
Otherwise, a reader who does not look at the base class would have no way of
knowing that "somefunction" was virtual. Some people prefer to use a
variation of Hungarian notation to indicate the "virtual-ness" of a function
(e.g. "vSomeFunction"), but I wouldn't advocate this.

What's interesting to me is that the language does not allow you to include
the "virtual" keyword in the definition, only in the declaration. So much
for consistency!

- Dennis

 

[Pete Becker]

Oh, I should point out that while including "virtual" in derived classes
does no harm, it certainly makes it clear that the function is virtual.
Otherwise, a reader who does not look at the base class would have no way of
knowing that "somefunction" was virtual.

However, marking it "virtual" in the derived class won't help this
clueless programmer to know what its purpose is, because without looking
at the documentation for the base class there is no way to know that it
is defined in the base class and overridden in the derived class.

 

[red floyd]

hi all,
i have 2 classes and a virtual function:


class BaseClass
{ public:
virtual void somefunction();
};

class DerivedClass : public BaseClass
{ public:
/*virtual*/ void somefunction();
};

This seems to work even when I drop the 'virtual' keyword in the derived
class. Does this make any difference? Or is the second 'virtual' in the
derived class obsolete?

It's not necessarily obsolete, but it is redundant. Once it's virtual
in the base, it's virtual in the children.

 

[Thomas]

ok, got it. Thanks everybody

 

[David White]

Oh, I should point out that while including "virtual" in derived
classes does no harm, it certainly makes it clear that the function
is virtual. Otherwise, a reader who does not look at the base class
would have no way of knowing that "somefunction" was virtual.

But 'virtual' on the derived class function doesn't mean that it's virtual in the base
class, although you would normally expect it to be. It only means that it's virtual for
that class and its derived classes. If you hope to use base-class pointers pointers
polymorphically, you still need to check the base class to be sure which members are
virtual.

Some
people prefer to use a variation of Hungarian notation to indicate
the "virtual-ness" of a function (e.g. "vSomeFunction"), but I
wouldn't advocate this.
Yuk.

What's interesting to me is that the language does not allow you to
include the "virtual" keyword in the definition, only in the
declaration. So much for consistency!

Well, it's always redundant for the definition. It's the same for class static functions.

DW