Sign in to follow this  

Protecting method access in C++, other approachs

This topic is 4108 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, Been working on my ResourceMgr class for the 2D Engine I have been working on and I was wondering if anybody has an alternative approach to doing things the work enforce access restrictions easier than the way I am approaching it at this point of time. Design wise I have - a ResourceMgr - a singleton class - Other SubManager that are allowed access to protected functions under the Resource Mgr.

class ResourceMgr
{
 friend IResourceMgr
 protected(or private)
   int poo(y);
}


class IResourcMgr
{
  protected:
     mResourceMgr * mMgr(Singleton initiatezed on construction)
  public:
     int doo(x);
     int da(z);
}

class TexutreMgr : public IResourceMgr
{
   public:
      int moo(y);
}
DOH..have to add TextureMgr as a friend too!
My initial idea was to allow IResourceMgr to be interited by other sub managers but now comes the sticky bit..Inherited children don't have access to protected/private functions so I would have to declare that as a friend class as well What I don't like about this is that every 'new' submgr would pretty much have to be declared as a friend(Call me a lazy programmer if you like). The only way I can think out of this is to enforce access via the implementing some wrapper protected wrapper functions in IResourceMgr.

Share this post


Link to post
Share on other sites
Derived classes DO have access to protected members of the parent class. That is all that distinquishes private access from protected access.

Additionally, derived classes CAN override private virtual functions. They just can't CALL them.

Share this post


Link to post
Share on other sites
"Derived classes DO have access to protected members of the parent class. That is all that distinquishes private access from protected access."

Yes they do..but the child of a friend class does not have access unless explicitly said to have:

http://www.parashift.com/c++-faq-lite/friends.html#faq-14.4


Share this post


Link to post
Share on other sites
There's something about that design that I don't like, especially since you're already seeing problems from it. Try to redesign and think what's the most intuitive way to do what you think should be done.

Ideally, the abstract resource class should be doing all the internal stuff and calling all the private secretive methods in the manager. You don't want to be dealing with that lower level stuff when implementing a type of resource. Any functions you would call in the manager from a derived class would be considered public, as they are there to help the developer out.

Share this post


Link to post
Share on other sites

This topic is 4108 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this