Thread: Object to Object Access

Suppose I have the following code :

Code:

#include<iostream>

class A
{ 
int x;
public :
void input ()
{ std::cin>>x;
}

void add( A obj )
{ 
x=x+obj.x;
std::cout<<x;
std::cout<<++obj.x;
}
   };

int main()
{  A obj1,obj2;
obj1.input();

obj2.input();

obj1.add(obj2);
return 0;
}

This code executes properly , but my question is , If Obj2.x is a PRIVATE data member , then how is a Member function of Obj1 able to access obj2.x and manipulate it.

Is there a pre enabled or friend compliance between objects of the same class?

The private attribute of class members apply on a class-wide basis, not a per-object basis. All member functions (and friends) of class A can access any private members of any instance of A (as well as any private static members of class A). If that wasn't true, your code would not even compile.

The catch is that, in the call obj1.add(obj2), obj2 is being passed by value to add(). That means the add() function sees a copy of obj2, not obj2 itself. It therefore changes the copy, not the original. The copy is destroyed immediately after the function returns, and data is not copied back into obj2 inside main().

If you want the change of obj.x in the add() to be visible to the caller - i.e. for obj1.add(obj2) to directly modify obj2 - then change the add function so it accepts a reference argument.

Code:

    void add( A &obj )   // etc

Indentation for the code could certainly be improved. Indentation is important.

What exactly is your question? A copy constructor shall (in most cases) not modify whatever it's copying. In the code you've posted, it cannot make any changes to obj since it's const.

Yes, that's right. All instances of A can access the private members of all other instances of A.

Originally Posted by Arpan Das

I want to know why such a setting , was it planned to allow this? (...) Doesn't this conflict with access specifier's and there sole purpose of protecting data?

It does not conflict. Think about why access control exists in the first place. The idea is that some things should be restricted to the implementation because they are implementation detail that is more subject to change than an interface provided for use. This restriction could be established by convention, but access control establishes the restriction as a language feature.

Now, if you are writing the implementation of a member function, you have access to the restricted part of the current object, because you need it to implement. Would there be a problem allowing you access to the restricted part of another object of the class from within the member function? Of course not, because within that context you are dealing with the same implementation detail.