That's understood (in fact, the same could be done for "const"ness).
Instead, we're discussing what happens at compile time, when overloading a public virtual with a private changes the normal semantics of the "private" keyword.
Actually, I was just going to draw analogy to "const", but looks like this suffers from similar problems:
Code:
class EventHandler
{
public: virtual void handleEvent( ) { d++; }
int d;
};
class MyEventHandler : public EventHandler
{
// woops! there goes the "const"ness
// so much for empty promises
private: void handleEvent( ) const { (void)e; }
int e;
};
void handleEvents( EventHandler *eh )
{
eh->handleEvent( );
}
int main()
{
MyEventHandler meh;
handleEvents( &meh );
}
Surprisingly, "const"ness is violated here and still no warning is generated! These are the kinds of things I'd expect a compiler to flag (all the necessary information is present at compile time). The fact that private and const semantics can change so discreetly does seem a bit of a design flaw...