Today in university I was recommended by a professor that I'd check for (this != ©) in the copy constructor, similarly to how you should do it when overloading operator= . However I questioned that because I can't think of any situation where this would ever be equal to the argument when constructing an object. He admitted that I made a good point. So, my question is, does it make sense to perform this checking, or is it impossible that this would screw up? Edit: I guess I was right, but I'll just leave this open for a while. Maybe someone's coming up with some crazy cryptic c++ magic. Edit2: Test a(a) compiles on MinGW, but not MSVS10. Test a = a compiles on both, so I assume gcc will behave somewhat similar. Unfortunately, VS does not show a debug message with "Variable a used without being initialized". It does however properly show this message for int i = i . Could this actually be considered a c++ language flaw?
class Test < Test(const Test ©) < if (this != ©) // > Test &operator=(const Test &rhd) < if (this != &rhd) // > >; Your professor likely does not master C++ and should not be teaching it. It is almost never necessary to check for self assignment if you're using the copy-and-swap idiom. [I say "almost" because it is a form of (premature) optimization.]. If you don't know the copy and swap idiom, you must learn it, and learn not to write those creepy code duplicating self assignment testing memory leaking exception unsafe 15-line long assignment operators.
Commented Apr 1, 2011 at 19:55 @dialer: why flaw? I don't see any problem with this. Commented Apr 1, 2011 at 19:58@ybungalobill Because it enables you to create an object (the second a ) without calling any constructor for it (not even default constructor). When you then copy an unconstructed object, all your RAII endeavors will be screwed up. To make it worse, without further checking, the code won't even crash until destruction of the original © object. Sure, these assignments are nothing but wrong, but IMO they should also be considered wrong then, by K&R C already. Even copy and swap could screw up device handles etc.
Commented Apr 2, 2011 at 8:57Personally, I think your professor is wrong and here's why.
Sure, the code will compile. And sure, the code is broken. But that's as far as your Prof has gone with his reasoning, and he then concludes "oh well we should see if we're self-assigning and if we are, just return."
But that is bad, for the same reason why having a global catch-all catch(. ) which does nothing is Evil. You're preventing an immediate problem, but the problem still exists. The code is invalid. You shouldn't be calling a constructor with a pointer to self. The solution isn't to ignore the problem and carry on. The solution is to fix the code. The best thing that could happen is your code will crash immediately. The worst thing is that the code will continue in an invalid state for some period of time and then either crash later (when the call stack will do you no good), or generate invalid output.
No, your professor is wrong. Do the assignment without checking for self-assignment. Find the defect in a code review or let the code crash and find it in a debug session. But don't just carry on as if nothing has happened.