Package and virtual functions

[Jonathan M Davis]

On Thursday, June 14, 2012 01:34:42 BLM768 wrote:
> > override will eventually be required when overriding a
> > function. It is already
> > if you compile with -w but not yet all of the time - though
> > since protected
> > isn't virtual and isn't really overriding anything, the
> > compiler doesn't
> > complain if you don't use override with it (though it will if
> > you do, since
> > it's not overriding anything). So, eventually (or now if you
> > use -w), you will
> > _always_ know whether a function is overiding another or not,
> > because it will
> > have to have override if it is and can't have it if it isn't.
> > 
> > - Jonathan M Davis
> 
> That's good to know. I'll start using -w from now on.
> However, the problem still exists that if a function is meant to
> override a virtual method, but the method is not actually
> virtual, and the programmer forgets to type "override," the
> compiler won't complain and the error will slip through.

True enough, but then all it takes is looking at the function to know that 
it's not overriding anything (because it doesn't have override on it), and 
naming a function the same in a derived class when it's not virtual generally 
isn't a good idea, since it's _not_ overriding anything - the same happens 
with both protected and private. But there's really no fix for that other than 
making it illegal to have a private or protected function with the same name 
in derived classes, which then effectively leaks some of the private/protected 
API of the base classes into the derived classes rather than hiding it. So, 
it's not like there's really a perfect solution.

IIRC, the docs are quite clear that protected is non-virtual, but it's 
probably easy to miss.

- Jonathan M Davis