Reference to member variable

[sszd]

Is it possible to return a reference to a member variable in such a way as to prevent it from being altered (thereby changing the state of the object)? The following code does not prevent this!

 
class X
{
};
 
class Y
{
public:
	 const X& get () const { return _x; }
 
private:
	 X _x;
};

This does not stop someone from doing the following...

int main ()
{
X x;
Y y;
 
const_cast<X&> (y.get ()) = x;
}

[Paul McKenzie]

This does not stop someone from doing the following...

int main ()
{
     X x;
     Y y;
     const_cast<X&> (y.get ()) = x;
}

If a programmer decides to do this on purpose, let them suffer the consequences. In other words, change the programmer, not the code.

Regards,

Paul McKenzie

[KevinHall]

I agree 100% percent with Paul. I don't want to ever be working with that programmer.

[sszd]

If a programmer decides to do this on purpose, let them suffer the consequences. In other words, change the programmer, not the code.

I would have to agree, unfortunately it's usually not the original programmer that suffers the consequences, it's those that follow years later that are trying to debug such drivel. And I can't tell you how many times I've run across this very same type of garbage over the years.

[Andreas Masur]

Okay....nevertheless, I would not know of any way to prevent anyone from modifying even a constant object...the only way would simply be...don't give them references to the internals of your class...

[Graham]

If it was really important that you prevent pathological colleagues from perpetrating such idiocies then, given that there's a reason you can't just re-educate them with something heavy , your best bet is to return a proxy to the member, rather than a reference. If the proxy has no operator= defined, then they can't assign to the member. And you don't even need to make it const.

Of course, this approach make life a bit harder for the well-behaved programmers...

[jlatham]

I would have to agree, unfortunately it's usually not the original programmer that suffers the consequences, it's those that follow years later that are trying to debug such drivel. And I can't tell you how many times I've run across this very same type of garbage over the years.

I understand your making the effort, but I too agree with Paul. If this future programmer is trying to do something stupid, they will succeed, no matter how hard you try to prevent it.

A quote I like from Rich Cook sums it up: "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

[Kheun]

How about having some code review sessions for your entire team? At least, it can be served as a form of education so that new programmers can learn the rope from their senior. Beside that, it also helps to reduce defects from leaking into the testing phase, which is usually more costly to fix by then.