Thread: private class member access

I noticed this when I was doing some programming in my game.

Code:

struct coord
{
short int x;
short int y;
coord* cLP;//this is a linked list pointer
Character* cReside;//this points to a character object to indicate
                                //that a character is in this location
}

That is the gist of the coord struct. Now, when I was coding the targeting system, I inadvertently used the cReside pointer to access a private data member of the Character class, but much to my surprise, the program compiled!

Code:

cReside->pItem[1].Unequip

Now granted, the pointers of the coord struct are public, but the pItem array is still private in the Character class. Can somebody tell me why this access is possible?

Code:

class Character
    {
    public:
        TryThis(Character*);
    private:
        short int Atk;
        short int Def;
        //other data here, yadda yadda
    };

void Character::TryThis(Character* arg1)
    {
    arg1->Atk=1234;
    }

int main()
    {
    Character DummyNumber1;
    Character DummyNumber2;

    DummyNumber1.TryThis(&DummyNumber2);
    return 0;
    }

This is perfectly legal. You acces a private member of of an object from within a memberfunction of that objects class. And yes it doesn't matter that it is a member of another instance of that class.
Kurt

I wanted to make sure becuase as long as I have been programming this is the first time I have run into that situation. Considering the whole concept of "data hiding", I was surprised to find that it was possible to do that, as I had never tried to do so deliberately. If I needed to access private data from a different instance of a class, I would just use the normal interface functions that would have to be used when executing externally to the class.

Originally Posted by DarkMasterBosel

I wanted to make sure becuase as long as I have been programming this is the first time I have run into that situation. Considering the whole concept of "data hiding", I was surprised to find that it was possible to do that, as I had never tried to do so deliberately. If I needed to access private data from a different instance of a class, I would just use the normal interface functions that would have to be used when executing externally to the class.

One, it makes sense from a logical standpoint to allow one object to modify another object of the same class. There should be no danger of messing up internal state, because the whole point of the class is to understand how to maintain its own internal state. If one object is messing up another object of the same class, it means your code is buggy, not that you're defeating encapsulation.

Two, even if the compiler tried to prevent you from changing another object, it would be pointless, since you could make it happen anyway by writing a member function which did the same manipulation and invoking it on the other object. For instance, suppose the compiler did NOT let you do this:

Code:

class a
{
    void frob(a &other) { other.x = 123; }
    int x;
};

Well hell, you'd just do this:

Code:

class a
{
    void frob(a &other) { other.frobYou(); }
    void frobYou() { x = 123; }
    int x;
};

Right?