检查“自我分配”。在复制构造函数中? [英] Check for "self-assignment" in copy constructor?

查看:75
本文介绍了检查“自我分配”。在复制构造函数中?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

今天在大学里,一位教授推荐我在复制构造函数中检查(this!=& copy) operator = 重载时显示。但是我提出了疑问,因为我无法想到在构造对象时 this 永远等于参数的任何情况。

Today in university I was recommended by a professor that I'd check for (this != &copy) 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?

编辑:我想我是对的,但是我会暂时打开它。也许有人想出一些疯狂的神秘C ++魔术。

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 测试a(a) 在MinGW上编译,但不能在MSVS10上编译。 Test a = a 都在两者上编译,所以我认为gcc的行为会有些相似。不幸的是,VS不会显示调试消息,并带有变量a已使用而未初始化 。但是,它确实正确显示了 int i = i 的消息。

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


推荐答案

我个人认为您的教授错了,这就是为什么

Personally, 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."

但是这很糟糕,出于同样的原因,为什么拥有一个全能的 catch(...)什么也不做是邪恶的。您可以防止遇到直接问题,但问题仍然存在。该代码无效。您不应该使用指向self的指针来调用构造函数。解决方案不是忽略问题并继续下去。解决方案是修复代码。可能发生的最佳事件是您的代码将立即崩溃。 最糟糕的问题是代码将在无效状态下持续一段时间,然后稍后崩溃(当调用堆栈对您不利时),或生成无效输出。

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.

这篇关于检查“自我分配”。在复制构造函数中?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆