Archived

This topic is now archived and is closed to further replies.

The three P's Public Private Protected

This topic is 5181 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

I got a question that my book doesn''t really explain a whole lot about. I understand the properties of variables in the sence that public variables can be accessed by nearly everything, and private only member functions (etc...). But what the book didn''t tell me is why we have Public, Private, and Protected. Why are they there? As far as I know private variables can''t be accessed by outside applications, or am I wrong? When it comes to security, which variable properties should be used, and what advantage does one have over another? Thanks in advance ~David

Share this post


Link to post
Share on other sites
if you have the class someclass defined like this

class someclass
{
public:
someclass();
~someclass();

void setvar(int var);
int getvar();

int publicvar;
private:
int privatevar;
};

someclass::someclass()
{
publicvar = 12; // ok
privatevar = 13; // ok, because we are a member function
}

void someclass::setvar(int var)
{
if(var > 0)
privatevar = var; // ok, we are member
else
privatevar = 0;
}

int someclass::getvar()
{
return privatevar;
}

int main()
{
someclass theclass;
int someint;

theclass.publicvar = 2; // this is ok
theclass.privatevar = 2; // error, the member is private
// so to have access to the privatevar you must do
theclass.setvar(2); // this sets privatevar to 2
someint = theclass.getvar();
// this is used to manipulate variables safely
// in someclass::setvar you can do bounding checks, etc
// also a lot of people recommend setting all your variables
// private and making functions to access them
return 0;
}


damn i'd like to know how to make those textboxes



[edited by - lemurion on October 10, 2003 4:12:41 PM]

Share this post


Link to post
Share on other sites

class Foo
{
public:
void FooFunct();
int m_PublicInt;
protected:
int m_ProtectedInt;
private:
int m_PrivateInt;
};


class FooBar : public Foo
{
public:
void FooBarFunct();
};


m_PublicInt: Any code can access it.
m_ProtectedInt: Only FooFunct() and FooBarFunct() can access it.
m_PrivateInt: Only FooFunct() can access it.


Value of good ideas: 10 cents per dozen.
Implementation of the good ideas: Priceless.

Proxima Rebellion - A 3D action sim with a hint of strategy

[edited by - BS-er on October 10, 2003 4:17:17 PM]

Share this post


Link to post
Share on other sites
Oh, I understand that, but I'm talking about outside applications modifing your program variables. Is there any difference declaring it public or private? Me personally, I use the get\set function approach, so I guess that is the right way.

PS lemurion: use the (source) (/source) tags *change ( with [ and ) with ]

[edited by - PumpkinPieman on October 10, 2003 4:18:27 PM]

Share this post


Link to post
Share on other sites
The purpose is not security from hackers, outside applications, or forces of nature. The purpose of private variables is rather to enforce good coding practices, to help with data encapsulation, and to aid the programmer in separating interface from implementation. By forcing people to interact with an objects through its methods, you can use those methods to do error checking on parameters, and if the internal details of your class change (for instance, you may represent internal state with different data types) the methods other people use to access it can remain unaltered - which means that although you switched from keeping an object''s data in a linked list to a fancy self-balancing tree, people can still call the object''s insert() method. If you allow unrestricted (public) access to the object''s member, there''s always the risk that someone just went through the linked list, and code will break.

Share this post


Link to post
Share on other sites
quote:
Original post by PumpkinPieman
Oh, I understand that, but I''m talking about outside applications modifing your program varibles. Is there any difference declaring it public or private? Me personally, I use the get\set function approach, so I guess that is the right way.

PS use the (source) (/source) tags *change ( with [ and ) with ]


If you mean outside applications like debuggers, hex editing program or something of that nature then yes they can modify your program variables if you know how to use them.

The purpose of the different access specifiers are just there to help facilitate the idea of encapsulation in OOP; that''s the reason for it''s existance. It has little to do with security in the sense where you keep a hacker or some external program from messing with your program.





--{You fight like a dairy farmer!}

Share this post


Link to post
Share on other sites
I guess you''d have to be more explicit. Applications that are running in their own memory space may have a tough time getting to member variables or even member functions, unless you use COM, or some other interface that lets applications talk.

Or did you mean to say other classes vs. other applications?

If you elaborate on exactly what you''re trying to do (DLL, COM, other) we may be able to answer better .

Value of good ideas: 10 cents per dozen.
Implementation of the good ideas: Priceless.

Proxima Rebellion - A 3D action sim with a hint of strategy

Share this post


Link to post
Share on other sites
Heh heh to make the code windows, start it with the word source but in square brackets, and end it with the word /source also in square brackets.

Pumkinpieman, what kind of security are you talking about. code protection security where your code is in a library? There are certainly ways around that in order to peek at the contents of an object, although you could scramble that with an interface class that hides the real class or somesuch. I guess I need to understand what you are trying to do, or I may end up rambling on about something you don''t care about .

Value of good ideas: 10 cents per dozen.
Implementation of the good ideas: Priceless.

Proxima Rebellion - A 3D action sim with a hint of strategy

Share this post


Link to post
Share on other sites
I''m not too familiar with the terms code injection, and such. I just started C++ a few months ago, before that I was fluent in OO type programming in different languages, but things like security didn''t matter much to me. Now, I''m trying to make a game, and I''m trying to devolop skills to make a game that can''t be easily modified by anything of such nature outside the application it''self. I know there are programms like hackman which can view memory and such, but I''m not too fluent in how people go about creating applications that modify variables of another program. Which is what happens with cheats, right? I just remembered hearing somewhere that private variables are more protected in memory then a public one. So I wasn''t too sure which one was more secure. So I started writing my program with all private variables and get\set functions \ overloaded operators and such.

Share this post


Link to post
Share on other sites
Using get/set methods (for variables that actually need to be altered by other objects/functions/whatever) and making your member data private is generally considered practice. However, while you are guarding against programming mistakes and employing techniques that help with data encapsulation and detaching interface from implementation, I do not believe that you are in any way protecting your data from interference from outside/malicious applications. (I know nothing about such applications, but I have never heard of anything that would indicate that access modifiers protect against such manipulation; see also Stroustrup, 10.2.2.)

Share this post


Link to post
Share on other sites
For things like this
lstrcpy()
Security Alert Using this function incorrectly can compromise the security of your application. The first argument, lpString1, must be large enough to hold lpString2 and the closing ''\0'', otherwise a buffer overrun may occur. Buffer overruns may lead to a denial of service attack against the application if an access violation occurs. In the worst case, a buffer overrun may allow an attacker to inject executable code into your process, especially if lpString1 is a stack-based buffer. Consider using one of the following alternatives: StringCbCopy, StringCbCopyEx, StringCbCopyN, StringCbCopyNEx, StringCchCopy, StringCchCopyEx, StringCchCopyN, or StringCchCopyNEx. You should review Security Considerations: Windows User Interface before continuing.

Security wise, is that all that can happen? BTW I''m using std::string, so this is just an example.

Share this post


Link to post
Share on other sites
As far as I know, those three terms only mean somthing to the compiler while it is compiling. They are only there to promote good coding practise and encapsulation.

When it is compiled, all that stuff just falls away anyway, so they wont actuly affect anything while the code is running, and thus, wont help you with outside influences.

Share this post


Link to post
Share on other sites
That is my understanding as well. They are just rules for compilation and linking. Bjarne Stroustrup himself said this:

quote:
original quote by Bjarne Stroustrup (ARM,1990)
The C++ access control mechanisms provide protection against accident-- not against fraud.





==================
Benjamin Heath
==================

[edited by - Benjamin Heath on October 11, 2003 2:30:08 AM]

Share this post


Link to post
Share on other sites