On Mon, 25 Jul 2005 14:59:57 GMT, Shea Martin <sh***@hb-studios.com>
wrote:
Virtual just specifies which function gets called when polymorphism is
in action. For example:
Generally speaking, it is stylistically inappropriate to do this sort
of overriding when dealing with polymorphism. In C++, the 'class'
mechanism is reused for several different purposes (concrete, abstract
bases, mixin implementation, vanilla polymorphic, trait, etc) for each
of which certain features are inappropriate to use. You can contrast
this to Java, where classes are user-defined polymorphic types, and
pretty much nothing else.
It's worth pointing out that this non-virtual override is not the same
function as it's parent's function; it just happens to share the same
signature.
Used from the base class type, the object will still operate correctly
and as expected. The only trouble here is if a user is using the
object as the derived type, without consulting the class
documentation, and expecting it to work properly. But this is the
same with non-virtual overriding or no: blindly using an interface
without consulting the documentation may result in strange things.
Besides, why are they using the derived type if they want guarantees
provided only by the parents?
Since this sort of thing is a misuse anyway, why do you care?
Many compilers can be configured to give a warning for this situation.
It's too bad that many low quality textbooks (and low quality
universities) continue to teach non-virtual overriding, often eliding
discussion of 'virtual' itself entirely.
But no, to answer your question, this is not possible without doing
something very invasive, such as parameterizing the base class with
the type of the derived.
Aaron W. LaFramboise