C++ class security
Author
How protective are class access levels exactly?
I figure I am able to edit any member I wish as long as I have the class return a pointer to a member I choose. Are there any more work-arounds or good habits to increase efficiency or bypass class security?
If you return a non-const pointer or reference to a member then yes this can result in a "bypass" of the access modifier system. However, they can be subverted easily by a determined programmer. They are purely compile time construct, so once a binary is built they don't do anything.
Can you focus your question a little more?
Efficiency isn't an issue in general purpose code, in a given program 90% of the time will be spent in 10% of the code. So don't try to prematurely optimise. Just write the code in the most obvious and maintainable way. Then change it later if you profiler tells you there is a problem.
Security isn't really a great term to use here. Access modifiers don't provide any security. Used properly, they limit the scope of state modification, which can make it easier to demonstrate that code is correct.
Can you focus your question a little more?
Efficiency isn't an issue in general purpose code, in a given program 90% of the time will be spent in 10% of the code. So don't try to prematurely optimise. Just write the code in the most obvious and maintainable way. Then change it later if you profiler tells you there is a problem.
Security isn't really a great term to use here. Access modifiers don't provide any security. Used properly, they limit the scope of state modification, which can make it easier to demonstrate that code is correct.
There are actually about 2-3 different ways around class access security. If the class members are labeled private then only that class can directly access those items. If they are labeled protected any sub-class from the base class can have direct access to the base class member variables as well as its own member variables. Also if you dont prefer to use the protected members pointers are a way to get around it so you do not "slice off" information from the sub-class.
Here is a very simple example of what I am trying to talk about:
So if the member variables in BaseClass are private then what_x can would have to call get_x to get that information it wouldnt be allowed to call x directly.
As for pointers they can be used in a similar fashion regardless of protected/private, example:
Now c has both x and y values available to it. Hope this was what you were talking about.
Here is a very simple example of what I am trying to talk about:
class BaseClass{public:// functions hereint get_x() const { return x }protected:// member variables hereint x;};class SubClass: public BaseClass{public:// functions here you have access to all BaseClass functions as wellvoid what_x() { cout << x << endl }int get_y() const { return y } private:// member variables for SubClass and BaseClass member are available as wellint y;};So if the member variables in BaseClass are private then what_x can would have to call get_x to get that information it wouldnt be allowed to call x directly.
As for pointers they can be used in a similar fashion regardless of protected/private, example:
Base *b;Sub *c;c = new Sub;c->x = 12;c->y = 6;Now c has both x and y values available to it. Hope this was what you were talking about.
There is no such thing as "C++ class security". Access modifiers are a means of abstraction ("You don't need to worry about implementation details"), NOT a security system to prevent someone from touching your private parts.
Author
Quote:They are purely compile time construct, so once a binary is built they don't do anything.
Now this is news to me! That tidbit is actually a huge help to most of my uncertainties on classes.
Quote:Can you focus your question a little more?
I don't know how I can now, since my question was pretty much answered here... Except for what is said below.
toogreat, thanks for the examples! But in the second one, are you trying to tell me that making a pointer to a class removes access restrictions entirely...? I don't remember that being the case. Is it because you are using the heap there?
Quote:
There is no such thing as "C++ class security". Access modifiers are a means of abstraction ("You don't need to worry about implementation details"), NOT a security system to prevent someone from touching your private parts.
...Alrighty then.
I may/may not be right on this one but I believe you can only use the pointers I was showing you, if they are subclass of the baseclass, sorry for not mentioning that fact.
Quote:Original post by toogreat4u
(...)
If they are labeled protected any sub-class from the base class can have direct access to the base class member variables as well as its own member variables.
Only if you use public inheritance. With protected or private inheritance, access levels are degraded respectively one and two levels (so public becomes protected or private, and protected becomes private).
Quote:Also if you dont prefer to use the protected members pointers are a way to get around it so you do not "slice off" information from the sub-class.
Nope. Pointers do not change access levels and slicing has nothing to do with it.
EDIT: Pointers can be used to bypass access levels, if a member function returns a pointer or reference to a private variable. Then, outside code can change that variable through the given pointer (but still not directly):
class TestClass{public: int* ModifyMe() { return &x } // Returns the address of xprivate: int x;};TestClass test;int* tx = test.ModifyMe();*tx = 5; // test.x is now 5I wouldn't recommend doing the above though. It can be useful sometimes, but access levels are there to make your code more manageable. Working around them only makes your code harder to manage again...
Author
Alright, so what I'm getting here is...
When declaring inheritance for a subclass, public, private and protected become more of a level of how much to change access restrictions for the sub class, where public shifts everything to be more available, and private puts more of a lockdown.
So say I'm having ClassB inherit from ClassA. Also, Assume ClassB has no unique members of it's own.
Here's classA.
If ClassB has public inheritance, private becomes protected, protected becomes public. (if public shifts one level to higher access...) If protected, float_member becomes protected and short and int become private. If private, a severe lock down (so to speak) takes place and everything heads to private.
Based on their changes, I plan my use of the members from there.
Am I missing anything?
When declaring inheritance for a subclass, public, private and protected become more of a level of how much to change access restrictions for the sub class, where public shifts everything to be more available, and private puts more of a lockdown.
So say I'm having ClassB inherit from ClassA. Also, Assume ClassB has no unique members of it's own.
Here's classA.
class ClassA{public: float float_member;protected: int int_member; short short_member;private: long long_member;};If ClassB has public inheritance, private becomes protected, protected becomes public. (if public shifts one level to higher access...) If protected, float_member becomes protected and short and int become private. If private, a severe lock down (so to speak) takes place and everything heads to private.
Based on their changes, I plan my use of the members from there.
Am I missing anything?
Quote:Original post by zyrolasting
If ClassB has public inheritance, private becomes protected, protected becomes public.
No, access levels either stay the same or they degrade to a more restrictive level. Actually, I think my previous post wasn't entirely correct. It seems that protected inheritance only changes public base-class members to protected ones (for a proper explanation, read this). Public inheritance doesn't change a thing though, and that's the most important one to know about.
In the end however, I only use public inheritance, and I tend not to use it too much. Typically I end up with a few small, flat inheritance hierarchies, and a lot of composition (objects that contain instances of other classes as member variables, rather than deriving from those classes).
C++ and security don't mix in general. It is a big mess, but it is totally true. C++ will gladly let you ruin anything and circumvent anything. For a fun tidbit to illustrate this point, consider the following:
Public/Private/Protected are designed to facilitate your programming by allowing you to erect barriers. These barriers are a lot like crime scene police tape though, in that they are only effective so long as you choose to respect what they are trying to communicate to you. They offer you a mechanism to convey meaning to others who would use your code, not force limitations.
class SuperSecret{private: int value;// nobody may access this};class NotSoSecret{public: int value;// anybody may access this};int StealSecretValue(SuperSecret* a){ NotSoSecret* b = (NotSoSecret*)a; return b->value;//Stealing your secret value, //since in memory, NotSoSecret::value overlaps SuperSecret::value}Public/Private/Protected are designed to facilitate your programming by allowing you to erect barriers. These barriers are a lot like crime scene police tape though, in that they are only effective so long as you choose to respect what they are trying to communicate to you. They offer you a mechanism to convey meaning to others who would use your code, not force limitations.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
