   Derived class redefining Non-Virtual Base Function
  Im wondering if this is poor style or not.Here is the actual example from my code. I have a "Button" class, which includes a function to set the sprite names for each of its 4 states : normal, mouseover, mousedown and disabled. The function is defined like this (note it is not virtual)void SetSprites(const std::string& strNormalSprite, const std::string& strMouseOverSprite, const std::string& strMouseDownSprite, const std::string& strDisabledSprite);I have derived a class from this base button class called "ToggleButton" which acts like a button but has 2 states - toggled or untoggled. This requires 2 extra sprites to be set - the NormalSelected sprite, and the SelectedMouseover sprite, and is defined like thisvoid SetSprites(const std::string& strNormalSprite, const std::string& strMouseOverSprite, const std::string& strMouseDownSprite, const std::string& strDisabledSprite,  const std::string& strSelectedSprite, const std::string& strSelectedMouseOverSprite);The compiler now gives me an error when i call setsprites on a togglebutton with only 4 parameters (which is what i want). Is this reasonable practice, or could this cause the end of civilisation as we know it?Alex   
  It is generally not a good idea because if you call the base class function, then the derived class could be put into an invalid state.The reason it can't find the base class function is because you are overloading it (as opposed to overriding it) in the derived class. If you want to call the base class version then you must cast the pointer to point to the base class.You can avoid having to cast by using a using declaration. If you include the line "using Button::SetSprites;" in the ToggleButton class, then Button::SetSprites is accessible as though it is in ToggleButton.This doesn't fix the problem of the base class function resulting in an invalid state in the derived class. However, it can help avoid it. If you derive from a class and you only want some of the functions in the base class accessible, then you derive privately and use the using declaration to expose the functions that you want to allow. Here is an example:using namespace std;   class X    {    public:   void a() { cout << "A" << endl; }   void b() { cout << "B" << endl; }    };   class Y : private X    {    public:   using X::a;   void c() { cout << "C" << endl; }    };   int main(int argc, char * argv[])    {   Y y;   y.a();    //y.b();    // not accessible   y.c();   return 0;    } ;  Thanks for the info John. Playing with your method, one side effect i've found is that i can no longer convert a pointer to my derived object to the base class, so in the example you gave, i cant doX* pY = &yas i get a Conversion Exists but is inaccessible error. Is this unavoidable?Quote:This doesn't fix the problem of the base class function resulting in an invalid state in the derived classCan you explain why we get an invalid state, or where i should be looking to find info on this? ive googled without any luck.Alex   ;Quote:Original post by Aface[...]Can you explain why we get an invalid state, or where i should be looking to find info on this? ive googled without any luck.[...]Consider the following:ToggleButton *Toggler = new ToggleButton();NormalButton *BasePtr = Toggler;BasePtr->SetSprites("Normal", "MouseOver", "MouseDown", "Disabled");Since SetSprites is not virtual (and can't be since you completely change the signature), the base function is called, which will likely do the wrong thing.   ;  The reason for that error is that Y derives  from X privately. That is intentional -- it prevents the user of Y from calling functions in X that might break Y. Consider a class Square which is derived from Rectangle. Rectangle has the function SetWH( int w, int h ) and Square has a function SetSize( int s ). You don't want the user of Square to be able to set the width and height to different values because that would break Square, so you derive from Rectangle privately in order to prevent access to it.BTW, deriving Y from X publicly means that "Y is an X". Deriving Y from X privately means "Y is implemented in terms of X", and Y is not an X as far as anyone else is concerned.   