Is the following code Standard compliant ?

**manasij7479** · 05-05-2011

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' ?

**grumpy** · 05-05-2011

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

**phantomotap** · 05-05-2011

Code:

test(X p)

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

Soma

**manasij7479** · 05-07-2011

..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..

**VirtualAce** · 05-07-2011

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

**manasij7479** · 05-07-2011

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

**MK27** · 05-07-2011

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.

**iMalc** · 05-08-2011

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'.

**Elysia** · 05-08-2011

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

**boyhailong** · 05-08-2011

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 ！

**dwks** · 05-08-2011

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).

Thread: Is the following code Standard compliant ?

Thread Tools

Search Thread

Display

Is the following code Standard compliant ?

Similar Threads

Can vc++2005eebe set up to be ansi C compliant

Where to find the code that defines standard Functions?

How to make Dev-C++ more C99 compliant ??

Problems with standard WIN32 Code

Source code of C standard library...