Should a derived class redefine ("override") a member function that is non-virtual in a base class?, C++ FAQ

C++ FAQ / Section 23 / FAQ 23.8

Section 23:

23.1	Is it okay for a non-`virtual` function of the base class to call a `virtual` function?
23.2	That last FAQ confuses me. Is it a different strategy from the other ways to use `virtual` functions? What's going on?
23.3	Should I use protected virtuals instead of public virtuals?
23.4	When should someone use private virtuals?
23.5	When my base class's constructor calls a `virtual` function on its `this` object, why doesn't my derived class's override of that `virtual` function get invoked?
23.6	Okay, but is there a way to simulate that behavior as if dynamic binding worked on the `this` object within my base class's constructor?
23.7	I'm getting the same mess with destructors: calling a `virtual` on my `this` object from my base class's destructor ends up ignoring the override in the derived class; what's going on?
23.8	Should a derived class redefine ("override") a member function that is non-`virtual` in a base class?
23.9	What's the meaning of, `Warning: Derived::f(char) hides Base::f(double)`?
23.10	What does it mean that the "virtual table" is an unresolved external?
23.11	How can I set up my class so it won't be inherited from?
23.12	How can I set up my member function so it won't be overridden in a derived class?

[23.8] Should a derived class redefine ("override") a member function that is non-virtual in a base class?

It's legal, but it ain't moral.

Experienced C++ programmers will sometimes redefine a non-virtual function for efficiency (e.g., if the derived class implementation can make better use of the derived class's resources) or to get around the hiding rule. However the client-visible effects must be identical, since non-virtual functions are dispatched based on the static type of the pointer/reference rather than the dynamic type of the pointed-to/referenced object.