Thread: Overloading, Overriding, and Hiding - help?

Originally Posted by deoren

I also worked through the example classes you mentioned and got the behavior you described, and was reminded of the same example in Larry Ullman's book. I believe I understood what he was trying to teach the reader, but the use of overload in the explanation is giving me a hard time.

I was just reading thru the thread on L.U.'s site and I think what you are missing here is the significance of this (from Chapter 8, Pg 260, Overriding And Overloading Methods - Larry Ullman's Book Forums):

Originally Posted by Larry

if you *intend* to override method a(), but inadvertently overload the method, in both cases, the original definition of a() in the base class is no longer acceptable, but in the latter case, it's usage will have changed, too, which can be confusing

Which is what I was trying to say with the Animal-Dog-Cat example (hopefully you picked up on the idea that Animal is the base of Dog and Cat, I forgot to make that explicit initially ).

In the other thread, you make a big deal of the fact that (in C++), accidentally not matching the signature of a method you want to override from a base class will not really overload it by default, because by default (in C++), you have hidden the identifier (name) -- effectively, there is now only one method accessible by that identifier, so there is no "overloading". It's good that you get this point and understandable that you are hung up because...

Here's a personal observation: I used "In C++" because the majority (I'd bet, the vast majority) of C++ programmers have at least some knowledge of another formal OO language, and the majority of OO languages do not have this default "feature" (hiding). Since it's easy to negate via the "using" thing, there is no point in saying this feature is actually dumb (which it would be otherwise). It's optional, and having options is good. But this concept of hiding is not intrinsic to the concept of OOP, there being a collection of OOP languages, few of which deploy the term "hiding" in this sense (and some of which deploy the term "hiding" in a different sense).

However, (I'd wager that) pretty much all OOP languages permit overriding and where applicable, most permit overloading. So the morale of the personal observation is: beware the idiom. It makes sense that proponents and developers of C++ discuss it in terms of a more general understanding of OOP (because a significant part of their audience is there) and so at the same time, they are also explaining that understanding, via C++, to people that are totally new to OOP.

Going back to the Larry quote and the Animal-Dog-Cat thing, the significance here is something true in any OO language: that when you override a method, you need to do it properly, because this ensures the interface remains consistent with that of the base class. A consistent interface is crucial -- it's the difference between building a bridge and painting yourself into a corner. Because of the idiom, this is presented in relation to overloading, altho as you observe, that is not effectively what happens (by default) in C++.

But don't get too hung up on all this. I think by now the key concepts have registered on you and as you move on and do practical things you'll remember those and they'll become clearer thru application.

I'm now fairly confident I understand what you were saying with the Animal-Dog-Cat example:

Code:

// http://cboard.cprogramming.com/cplusplus-programming/146473-overloading-overriding-hiding-help.html#post1092465


#include <iostream>
using std::cout;
using std::endl;


class Animal 
{
public:

    virtual void speak()
    {   cout << "Animal::speak()" << endl;  }
};

class Dog: public Animal
{
public:

    void speak(int)
    {   cout << "Dog::speak()" << endl; }
};

class Cat: public Animal
{
public:

    void speak()
    {   cout << "Cat::speak()" << endl; }
};

int main(void)
{

    Animal a;
    Cat c;
    Dog d;

    // Classic inheritence/polymorphism: overridden base class function
    a.speak();
    c.speak();

    // except for this one, which does not override Animal::speak()
    // but instead hides it from a derived class object
    d.speak(1);

    // d.speak(); // this would fail

    cout << endl << "Now calling speak() using base class pointer" << endl;

    Animal* aptr = 0;
    
    // set to Animal (base) class
    aptr = &a;
    aptr->speak();

    // set to Cat
    aptr = &c;
    aptr->speak();

    // set to Dog
    aptr = &d;
    aptr->speak();

    return 0;
}

Initially I wrote it without the improperly overridden Dog::speak() function, then to illustrate what you were talking about I went back and changed it to accept an int.

Thanks for reading that forum thread on L.U.'s site, and for the additional tips. I think you're right about the concepts becoming clearer through application.

When I was reading the last chapter in Beginning Visual C++ 2008 I was having a hard time understanding some of the operator overloading concepts, but it wasn't until I had do the exercises that I was able to sort things out (with a lot of help from the regulars here).

I'm hoping the same thing will happen at the end of this chapter.

Thanks again.