Is there any way to overload the access type of a member function in a derived class such that is can not be accessed by a pointer to the base class other than merely overloading the function with nothing in it?
public int getNumber();
class derived : public base
private int getNumber();
base* mDerived = new derived();
would produce some kind of compiler error
The only ways I can think to get this effect would be to overload the function with nothing in the body, but this is bad form. Is there a way to make a compiler error occur when the overloaded function is called?
Ok, so here's more of what I want to do. I have a big class with many member functions. I am using that class as a part of another object, and I want that object to be able to send an object that controls the instance of the big class.
The controller would be a pointer to the controlled object (or some cast of it) that would make some functions, such as disconnect() in this case, unaccessable through this new pointer. In this way, the user can call all of the methods that do not hinder the object from working as intended inside the bigger class.
so basically, it's like this:
class bigObjectController : public bigObject
some way to hinder the user from calling disconnect()
If you dont want derived classes to have access to that function just make it private in the base class or make it virtual and override it in the derived class and when someone uses it you warn them saying its not implemented(by throwing exceptions or w/e) but yeah thats really ugly.
You could use a proxy class too. Using your code example:
Ok, sounds good. I suppose I will go with making the proxy object. Really, I was just looking for an easier way to, instead of defining every function the user CAN use, to instead define what they can not use, but perhaps that's me just being lazy. Either way, the derived class will always be able to be deleted, which is something that should not happen, so a controller object with a pointer pointing to bigObject seems like the only way to go.
Jon2029: as others have mentioned. It seems like you have a design flaw in your code somewhere.
Perhaps you want to extend the level of your Parent-Child relationship to include more than just 2 levels. So you have Class->Inhert->Inhert->etc.
This will allow you to better define the relationship.
Proxy objects are really a bad idea. They create ALOT of added maintenance and headaches. Trust me on this, I have worked on a large system where everything was proxyed and the task of doing work on this was very difficult.
Proxy classes (AKA handles) is far from being a indicative of a bad design. again to only use proxy objects on a project is, if all he wants is a way to use selected functions he can just make handle to that object he could even do it in a more polymorphic\generic way with templates.
The above proxy is a bad idea.
The proxy needs to be modified (added/deleted) every time something added/deleted in BigObject class and a base class pointer to bigObject would not be able to point (in terms of polymorphism) to bigObjectController as bigObjectController inherits from BigObjectProxy which is in fact a composite class of BigObject.