Jump to content
  • Advertisement
Sign in to follow this  
DudeMiester

Access Modifiers -- What's The Point? (Solved)

This topic is 5024 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've been experimenting with C++, and it seems that access modifiers (i.e. public/private) do nothing to change the underlying machine code that is produced and can easily be circumvented. It seems to me that they are merely a comment, and if that's the case why do we have them at all? "//" comments should do the job just as well. I've come to the conculsion that the only way to protect data, is to keep it unknown. That is, to make sure that the user doesn't have enough information about the data to make use of it. For example, while internally a class contains "int var1, var2, var3;", on the external frontend that the user manipulates the same code is shown as "char data[12];". This to me is the only true private data. So, as the topic states, what the point of access modifiers? imho, they can only serve to make a language overly complex. [Edited by - DudeMiester on January 16, 2005 12:38:26 PM]

Share this post


Link to post
Share on other sites
Advertisement
You get an error if you try to access an private variable. So access modifiers do work. They effectively hide the data from anyone outside the class. So....WTF are you on about?

Share this post


Link to post
Share on other sites
Not if you're smart you wont. For example:

class A
{
private:
int var1;
};

You want access to that var1?

class B
{
public:
int var2;
};

Then do:

A Test;
B* Test2=(B*)&Test;

Now you have access.

As I already stated, no data is hidden unless you hide the information about that data.

Share this post


Link to post
Share on other sites
Access modifiers are there to prevent people from messing with class data you want to keep out of them.
For example in string class - there's some storage for length of string. But if this is public, user can alter it and create unusable instance of class. This value should change only when you create/add/delete strings. So you need a way to say compiler, that this data is only accessible from within the functions defined in class (or friends of class) - so you put private/protected there.
As the names of modifiers say: public is for public use, so user won't screw anything when messing with public data. Private and protected members are for internal use only.
The difference between private and protected is how they behave in derived classes. Private members are not accessible from derived classes, protected are.

Share this post


Link to post
Share on other sites
True, but that's still merely a comment, like I stated. You're only saying, "I'd rather you not touch this data", which is done equally well by the code:

//I'd rather you not touch this data
int var;

EDIT:

I have the same issue with const, because with const_cast it no longer has any meaning. It too is merely a comment. I believe comments should be comments, code should be code, and the two shouldn't be mixed up.

Share this post


Link to post
Share on other sites
The point of access modifiers is to separate the public API which maintains class invariants and the private implementation which, if called externally, may not. They are stronger than comments because they can be enforced by the compiler. Of course you can get round them if you're going to get downright Machiavellian, but that's no reason not to have them. Should we abolish taxes just because rich people with well paid lawyers manage to get around them occasionally?

I'd recommend reading Uses and Abuses of Access Rights.

Enigma

Share this post


Link to post
Share on other sites
Don't think access modifiers are necessary? Consider this code:

class List
{
public:

class Node;
class Iterator;

Node* head;
int size;

List() : head(0), size(0) {}

Iterator add(int value);
void remove(Iterator node);
// etc.
};


void func1(List* list)
{
// do stuff if the list is empty
if(list->size=0)
{

}
}

void func2()
{
List list;
list.add(5);
func1(&list);
}




A very easy mistake to make, a very nasty bug to find.

EDIT: Well, any good compiler will spit a warning at you about this, but it's a good example of why access modifiers are necessary.

Share this post


Link to post
Share on other sites
So the basic idea is that while they are essentially "special" comments, they help avoid causing mistakes by messing with data you shouldn't be.

You see I'm coming from the direction of someone who wants to get access to that data, despite it's private nature. In that case, the method I mentioned is the only thing you can do to protect it. Even then you can probably reverse engineer it anyways, but it would be much more difficult and involving going through a lot of dis-assembly.

You see I'm writing some stuff that gives you detailed run time type information on classes, and I was wondering if it's worth differentating between public and private data and including logic to check access and whatnot. But then I realised you can get access anyways, so forget it. The only way to have really private data is to have no information on it. So I'm probably going to just set it up, so you can pick and choose what data in your class to have run-time info on. This creates a kind of public interface, that external classes can use to manipulate the class without actually knowing it's type.

Share this post


Link to post
Share on other sites
Quote:
they help avoid causing mistakes by messing with data you shouldn't be

Exactly.

Quote:
You see I'm coming from the direction of someone who wants to get access to that data, despite it's private nature. In that case, the method I mentioned is the only thing you can do to protect it. Even then you can probably reverse engineer it anyways, but it would be much more difficult and involving going through a lot of dis-assembly.

Well in cases where you don't want the variables to be visible even when looking at the header you can use the PIMPL (Private IMPLementation) design pattern (which can also be used when the exact details of the data, implementation, whatever aren't even known to the class). Here's an example:

Public header:

class MyClassImpl;

class MyClass
{
public:

MyClass();

// Interface functions, etc.

private:

// Implementation
MyClassImpl* impl;
};



Private source:

#include "MyClass.h"


class MyClassImpl
{
public:
int var1;
int var2;
};


MyClass::MyClass()
: impl(new MyClassImpl)
{
// you can now access your private data
// like this
impl->var1 = 0;
impl->var2 = 0;
}


Share this post


Link to post
Share on other sites
Quote:
Original post by joanusdmentia
Don't think access modifiers are necessary? Consider this code:
*** Source Snippet Removed ***
A very easy mistake to make, a very nasty bug to find.

EDIT: Well, any good compiler will spit a warning at you about this, but it's a good example of why access modifiers are necessary.

i dont see the mistake/bug

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!