Chapter 8, Pg 260, Overriding And Overloading Methods - Larry Ullman's Book Forums):
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 ).Originally Posted by Larry
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.