Is the following code Standard compliant ?

Code:

---

#include<iostream>
using namespace std;
class X
{
    private:
    int x;
    public:
    void d(){cout<<x;};
    void test(X p)
    {
        p.x = 10;
        this->x = p.x;
    };
};
int main()
{
    X a,b;
    a.test(b);
}

---

My question is about the bold lines... Can a member function called by another object 'see' the private members of the object in the argument?
It is compiling in gcc ....but I'd like to know if it is totally 'legal' ?

It is legal. All member functions of class X can access private members of any instance of class X.

Quote:

---

Code:

---

test(X p)

---

---

It is legal, but that may not be what you intended.

Soma

..I just wrote this example for illustrating the point...I wanted a member function called from one object to try and access private members of another..

It is legal, however confusing, and might be indicative of poor design in a larger system.

Would it be poor design if used in overloading operators ...when there are lots of private members ?

It isn't confusing, or unusual. This is a normative way of restricting how a member variable is used. For example, you may to allow access to the value of a non-const variable, so that it can only be changed by internal methods. So you make the variable private and have a public getter.

The use of the 'private' keyword is to prevent something or someone other than the implementor of the class, from directly seeing or changing certain things. It's not there to make one instance be oblivious to how another instance of the same class works. In this way, it isn't like 'const'.

It also stops people from deriving the class, usually. Because of this, I tend to use protected unless private is really necessary.

Code:

---

#include<iostream>
using namespace std;
class X
{
private:
        int x;
public:
        X():x(){};
        void d(){cout<<x;};
        void test(X p)
        {
                p.x = 10;
                this->x = p.x;
        };
};
int main()
{
        X a,b;
        a.test(b);
}

---

you can just add a default constructor， then ok ！

This surprised me too when I first learned of it. Strange that one object (albeit the same class) can access another's private members without being friends or something. But when you think about it, it makes sense. The compiler has to do static typechecking to see if you have permissions to access members instead of dynamic typechecking at runtime (since you want a compiler error when this happens, not a runtime one).

And it would take a lot of effort on the compiler's part to see if some member that you're accessing really belongs to the same object, and not another object of the same class. The compiler would have to track any pointer arithmetic you might be doing to try to fool it, to make sure the this pointer you end up with is the correct one. For example:

Code:

---

class Something {
    int x;
public:
    void f() {
        // if I know that x is always zero:
        (this + x)->x = 0;  // what is the compiler supposed to think of this?
    }
};

---

Since C++ classes are actually low-level, just functions associated with structures that always take a this* parameter, the compiler can't really do any better than this. And if I start using function pointers to member functions then the compiler's job just got even harder. :)

By the way -- it's not necessary to put a semicolon after the closing brace of functions and constructors etc. Just after the class definition itself (and after member variables, of course).