检查复制构造函数中的"自我赋值"？

Question

今天在大学里我被一位教授推荐,我会(this != &copy)在复制构造函数中检查,类似于你在重载时应该怎么做operator=.但是我质疑这是因为this在构造对象时我无法想到任何与参数相等的情况.

他承认我提出了一个很好的观点.所以,我的问题是,执行此检查是否有意义,还是不可能搞砸了？

编辑:我想我是对的,但我会暂时保持开放状态.也许有人想出一些疯狂的神秘c ++魔法.

Edit2:Test a(a)编译MinGW,但不编译MSVS10.Test a = a编译两者,所以我认为gcc会表现得有些相似.不幸的是,VS 没有显示"使用未经初始化的变量"的调试消息.但它确实正确地显示了此消息int i = i.这真的可以被认为是c ++语言的缺陷吗？

class Test
{
   Test(const Test &copy)
   {
      if (this != &copy) // <-- this line: yay or nay?
      {
      }
   }
   Test &operator=(const Test &rhd)
   {
      if (this != &rhd) // <-- in this case, it makes sense
      {
      }
   }
};

Answer 1

这是有效的C++并调用复制构造函数:

Test a = a;

但这没有任何意义,因为a它是在它初始化之前使用的.

Answer 2

就个人而言,我认为你的教授是错的,这就是原因.

当然,代码将编译.当然,代码被破坏了.但是,就你的教授推理他而言,他的结论是"哦,我们应该看看我们是否自我分配,如果我们是,那就回来吧."

但这是不好的,因为同样的原因,为什么拥有一个全球无所不能的catch(...)东西都是邪恶的.您正在阻止直接问题,但问题仍然存在.代码无效.您不应该使用指向self的指针调用构造函数.解决方案不是忽视问题而继续.解决方案是修复代码.可能发生的最好的事情是你的代码会立即崩溃.在最糟糕的事情是,代码将继续处于无效状态的一段时间,然后要么崩溃后(当调用堆栈会做你没有好),或产生无效的输出.

不,你的教授是错的.在不检查自我分配的情况下完成任务.在代码审查中查找缺陷或让代码崩溃并在调试会话中找到它.但是,不要只是继续,好像什么也没发生过.

Answer 3

如果您想变得偏执，那就：

class Test
{
   Test(const Test &copy)
   {
       assert(this != &copy);
       // ...
   }
};

如果您永远不想继续this == &copy。我从来没有打扰过这张支票。该错误似乎很少出现在我使用的代码中。但是，如果您的经验不同，那么断言可能是值得的。