'Overloading' Class member functions and Virtual functions

[nvangogh]

Hello,
My understanding is that a class member function can be overloaded -
that is to say, it's name can be used more than once so long as the
parameters are different.

So is the only advantage of overloading a class member function, the
fact that one does not have to think up alternative names for the
functions in a particular class that may do similar kinds of operation?
Is there a more fundamental reason for overloading a function? If not,
then it can safely be avoided altogether.

On another point, I have been introduced to the concept of 'Virtual
Functions' via a game project that I am currently working on. In my
studies of C++ I have not yet reached this particular topic which is
listed under 'advanced topics' in my book.

Many open source games seem to have lots of virtual functions in them.
My question is are virtual functions things that can be avoided - albeit
by using code that might not be as elegant? Obviously, the answer to
this will depend upon the particular problem being dealt with - but I am
hoping for general guidance on this point.

[Ben Bacarisse]

nvangogh <nvan...@invalid.net> writes:

> Hello,
> My understanding is that a class member function can be overloaded -
> that is to say, it's name can be used more than once so long as the
> parameters are different.
>
> So is the only advantage of overloading a class member function, the
> fact that one does not have to think up alternative names for the
> functions in a particular class that may do similar kinds of
> operation? Is there a more fundamental reason for overloading a
> function? If not, then it can safely be avoided altogether.

There is no fundamental reason for overloading but it the name of the
function is operator+=, then the advantage of keeping the name is not
inconsiderable.

> On another point, I have been introduced to the concept of 'Virtual
> Functions' via a game project that I am currently working on. In my
> studies of C++ I have not yet reached this particular topic which is
> listed under 'advanced topics' in my book.
>
> Many open source games seem to have lots of virtual functions in
> them. My question is are virtual functions things that can be avoided
> - albeit by using code that might not be as elegant? Obviously, the
> answer to this will depend upon the particular problem being dealt
> with - but I am hoping for general guidance on this point.

Any feature can be avoided; after all, C++ was first implemented as a
translator that turned C++ into C, but there is no sensible way to avoid
virtual functions if they make sense for a particular program. They
form part of the core that allows C++ to be used for object-oriented
programs.

--
Ben.

[Bill Gill]

Overloading is a very useful concept. Basically you can write
several functions and then use the same function name for a number of
different types. Ben Becarisse mentioned the += function. That is
obviously a good example of a very useful overload.

Virtual functions are very useful because you can use the function
in the children of a parent class while using the same function name,
even though it might be implemented slightly differently. So to
perform the same operation on a different child you call the same
function. It saves a lot of confusion over having each child use
a differently named function for the same type of operation on
different children.

If I didn't get that quite right keep in mind that I am still learning
this and forgive me. Hopefully somebody will correct me.

Bill

[Keith Thompson]

Bill Gill <bill...@cox.net> writes:
[...]

> Overloading is a very useful concept. Basically you can write
> several functions and then use the same function name for a number of
> different types. Ben Becarisse mentioned the += function. That is
> obviously a good example of a very useful overload.

Remember that both operators and functions can be overloaded.
Overloading is handy for things like, say, "insert", which could be
applied to any of a number of different data structures.

> Virtual functions are very useful because you can use the function
> in the children of a parent class while using the same function name,
> even though it might be implemented slightly differently. So to
> perform the same operation on a different child you call the same
> function. It saves a lot of confusion over having each child use
> a differently named function for the same type of operation on
> different children.

That's correct, but it doesn't really distinguish it from overloading.
They're both ways of having two or more functions with the same name,
but there are significant differences.

For a call to an overloaded function, it's always possible to determine
at compile time which function will be called. In essence, they're
syntactic sugar; you could eliminate overloading from a program by
giving all overloaded functions unique names.

On the other hand, if you have a pointer object like

parent *ptr;

then it could, at run time, point either to an object of the parent
class *or* to an object of a child class. If you then call

ptr->func();

and func() is virtual, then the determination of which function to call
is made at run time.

> If I didn't get that quite right keep in mind that I am still learning
> this and forgive me. Hopefully somebody will correct me.

More of an expansion than a correction.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bill Gill]

Thank you. I keep hoping to figure out how it all works. Every
little bit helps me along.

Bill