why should base class object points to derived class object (virtualfunction question) ?

[DanielJohnson]

While trying to understand the working principle of virtual functions,
I asked myself that why in this world do we need virtual functions at
the first place ?

Why do base class object needs to points to derived class object ?

I am a newbie and couldn't think of any legit reason. C++ guru please
enlighten me. I couldn't find the appropriate reason in C++ books.

Thanks

 

[zr]

While trying to understand the working principle of virtual functions,
I asked myself that why in this world do we need virtual functions at
the first place ?

Why do base class object needs to points to derived class object ?

I am a newbie and couldn't think of any legit reason. C++ guru please
enlighten me. I couldn't find the appropriate reason in C++ books.

Thanks

See
http://www.parashift.com/c++-faq-lite/basics-of-inheritance.html#faq-19.1
and the 3 the following FAQs.

 

[Juha Nieminen]

While trying to understand the working principle of virtual functions,
I asked myself that why in this world do we need virtual functions at
the first place ?

Why do base class object needs to points to derived class object ?

One example where virtual functions are very handy is with callback
interfaces.

Assume that you have, for example, a class named "MyClass", which has
a member function named "MouseClick(int x, int y)", and then you create
an instance of this class and you want to tell a GUI library "when the
user clicks a mouse button, call the MouseClick() function of this
instance". How would you do that?

You could make this GUI library so that it takes some function pointer
and calls that. However, a function pointer can only point to a regular
function, not the member function of an object, so there's no way to
automatically pass the object to this function. (The "MyClass" class may
have some member data needed in the implementation of "MouseClick()".)
One possibility would be that the GUI library takes the function pointer
and a void pointer to some unspecified data, and then passes this void
pointer to the callback function. This would work, but it's very ugly
and error-prone (for example you have to cast from void* to MyClass*
pointer in the function, and just assume that it's ok).

A much more elegant solution is for the GUI library to declare a
callback interface. In C++ this is simply a class with some (usually
pure) virtual functions. In this case it could be, for example, a class
named "MouseCallback" and have the "MouseClick()" function as a virtual
member function. Then "MyClass" would inherit from "MouseCallback" and
implement that function.

Now the GUI library can take a pointer of type "MouseCallback" even
though it's really pointing to an object of type "MyClass", and call the
"MouseClick()" function through that pointer, and the proper function of
"MyClass" will be called. The GUI library doesn't even need to know that
"MyClass" exists for this to work.

So here we have an example of a base class pointer pointing to an
object of a derived type, and a virtual function being called using this
pointer, which ends up calling the function in the derived class
(without the calling code having to even know what type the derived
class is). This is a pretty common technique.

 

[Daniel Pitts]

I think the question might be better asked backwards. We want run-time
polymorphism. We want "dynamic dispatch". A compiler could use run-time
resolution for all function calls, and the language would give all the
benefits of OO.

Why, then, do we not? Why would we ever want static-dispatch? Why would
we care if every function call was resolved at run-time?

One big answer is performance. Static dispatch is faster.

I for one would prefer the "safer" (eg dynamic) approach to be default,
and the engineer would have to request the "less-safe-by-faster" static
approach after determining the bottleneck.

Then again, I do a lot of Java programming, so maybe I'm spoiled

 

[Ian Collins]

I for one would prefer the "safer" (eg dynamic) approach to be default,
and the engineer would have to request the "less-safe-by-faster" static
approach after determining the bottleneck.

Safer in what way?

 

[James Kanze]

I think the question might be better asked backwards. We want
run-time polymorphism. We want "dynamic dispatch". A
compiler could use run-time resolution for all function calls,
and the language would give all the benefits of OO.

Why, then, do we not? Why would we ever want static-dispatch?
Why would we care if every function call was resolved at
run-time?

One big answer is performance. Static dispatch is faster.

That's rarely the reason. The main reason is security. The
more checking done at compile time, the more reliable and robust
the program. If a function can't be overridden, then you know
it fulfils its contract (since you wrote it).

 

[James Kanze]

I for one would prefer the "safer" (eg dynamic) approach to be
default, and the engineer would have to request the
"less-safe-by-faster" static approach after determining the
bottleneck.

Static resolution is the safer approach, by far. Making
functions virtual trades safety for flexibility, but designing a
robust base class is often harder than writing a complete,
non-polymorphic implementation, and you still have to add the
implemenation.

Then again, I do a lot of Java programming, so maybe I'm spoiled

But for a different meaning of "spoiled" than you think. Java
goes out of its way to make writing robust code difficult.

 

[James Kanze]

Performance is frequently a deciding factor.

Not for choosing between virtual and non-virtual functions---if
you don't need dynamic dispatch, you don't use it to begin with,
and if you need it, it's usually faster than the alternatives.

Most of the time virtual functions are appropriate, too,
involves more elaborate objects, with non-trivial functions, so
the difference in time is negligible.