检查复制构造函数中的“自赋值”？

Question

今天在大学里，一位教授推荐我在复制构造函数中检查 (this != &copy) ，类似于重载时应该如何做 operator= 。但是我质疑这一点，因为我想不出在构造对象时 this 永远等于参数的任何情况。

他承认我的观点很好。所以，我的问题是，执行此检查是否有意义，或者这不可能搞砸？

编辑：我想我是对的，但我会让这个打开一段时间。也许有人想出了一些疯狂的神秘 C++ 魔法。

Edit2 ： Test a(a) 在 MinGW 上编译，但不是 MSVS10。 Test a = a 两者都编译，所以我认为 gcc 的行为会有些相似。不幸的是，VS 没有 显示带有 “Variable a used without being initialized” 的调试消息。但是，它确实为 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
      {
      }
   }
};

原文由 dialer 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

就个人而言，我认为您的教授是错误的，这就是原因。

当然，代码会编译。当然，代码被破坏了。但这只是你的教授的推理，然后他得出结论：“哦，好吧，我们应该看看我们是否在自我分配，如果是，就回来。”

但这很糟糕，出于同样的原因，拥有一个全球通用的 catch(...) 什么都不做是邪恶的。您正在防止立即出现问题，但问题仍然存在。代码无效。您不应该使用指向 self 的指针调用构造函数。解决方案不是忽略问题并继续前进。解决方案是修复代码。可能发生的 最好 的事情是您的代码会立即崩溃。 最糟糕 的是，代码会在一段时间内继续处于无效状态，然后要么稍后崩溃（当调用堆栈对你没有好处时），要么生成无效输出。

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

原文由 John Dibling 发布，翻译遵循 CC BY-SA 2.5 许可协议

Answer 2

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

 Test a = a;

但这没有任何意义，因为在初始化之前使用了 a 。

原文由 Yakov Galka 发布，翻译遵循 CC BY-SA 2.5 许可协议