C ++成员函数中的“ if（！this）”有多糟糕？

如果我遇到if (!this) return;了应用程序中的旧代码，这有多严重的风险？它是危险的滴答定时炸弹，需要立即在应用程序范围内进行搜索并破坏工作，还是更像是一种可以悄悄放置的代码气味？

当然，我不打算编写执行此操作的代码。相反，我最近在一个旧的核心库中发现了一些东西，供我们的应用程序的许多部分使用。

想象一个CLookupThingy类具有非虚拟 CThingy *CLookupThingy::Lookup( name )成员函数。显然，在那个牛仔时代，一位程序员遇到过多次崩溃，这些崩溃CLookupThingy *是从函数传递NULL的，而不是修复数百个调用站点，而是安静地修复了Lookup（）：

CThingy *CLookupThingy::Lookup( name ) 
{
   if (!this)
   {
      return NULL;
   }
   // else do the lookup code...
}

// now the above can be used like
CLookupThingy *GetLookup() 
{
  if (notReady()) return NULL;
  // else etc...
}

CThingy *pFoo = GetLookup()->Lookup( "foo" ); // will set pFoo to NULL without crashing

我本周早些时候发现了这颗宝石，但现在在是否应该修复它方面发生了冲突。这位于我们所有应用程序使用的核心库中。这些应用程序中有几个已经交付给数百万个客户，并且看起来运行良好。该代码没有崩溃或其他错误。删除if !this查找功能将意味着修复成千上万个可能传递NULL的呼叫站点。不可避免地会遗漏一些，引入新的错误，这些错误会在下一年的开发中随机弹出。

因此，除非绝对必要，否则我倾向于将其保留。

鉴于这是技术上未定义的行为，if (!this)实际上有多危险？是否值得花几个星期的时间进行修复，还是可以依靠MSVC和GCC来安全返回？

我们的应用程序在MSVC和GCC上编译，并在Windows，Ubuntu和MacOS上运行。与其他平台的可移植性无关。保证所讨论的功能永远不会是虚拟的。

编辑：我正在寻找的客观答案是这样的

• “ MSVC和GCC的当前版本使用ABI，其中非虚拟成员实际上是带有隐式'this'参数的静态变量；因此，即使'this'为NULL，它们也将安全地分支到函数中”或
• “即将发布的GCC版本将更改ABI，以便即使非虚拟函数也需要从类指针中加载分支目标”或
• “当前的GCC 4.5具有不一致的ABI，有时它将非虚拟成员编译为带有隐式参数的直接分支，有时又编译为类偏移函数指针。”

前者表示代码很臭，但不太可能破坏；第二是在编译器升级后要测试的东西；后者甚至需要付出高昂代价立即采取行动。

显然，这是一个等待发生的潜在错误，但是现在我只关心减轻特定编译器的风险。

我不会理会它。作为SafeNavigationOperator的老式版本，这可能是一个有意的选择。正如您所说，在新代码中，我不推荐这样做，但是对于现有代码，我将不予理会。如果您确实要修改它，那么我将确保测试对其进行了全面覆盖。

编辑添加：您可以选择仅通过以下方式在代码的调试版本中将其删除：

CThingy *CLookupThingy::Lookup( name ) 
{
#if !defined(DEBUG)
   if (!this)
   {
      return NULL;
   }
#endif
   // else do the lookup code...
}

因此，它不会破坏生产代码的任何内容，同时使您有机会在调试模式下对其进行测试。

像所有未定义的行为

if (!this)
{
   return NULL;
}

这是一颗正在爆炸的炸弹。如果它可以与您当前的编译器一起使用，那么您会很幸运，很不幸！

相同编译器的下一个发行版可能会更具攻击性，并将其视为无效代码。由于this永远不能为null，因此可以“安全地”删除代码。

我认为删除它会更好！

如果您有许多GetLookup函数返回NULL，那么最好修复使用NULL指针调用方法的代码。一，更换

if (!this) return NULL;

与

if (!this) {
  // TODO(Crashworks): Replace this case with an assertion on July, 2012, once all callers are fixed.
  printf("Please mail the following stack trace to myemailaddress. Thanks!");
  print_stacktrace();
  return NULL;
}

现在，继续进行其他工作，但在滚动工作时进行修复。请替换：

GetLookup(x)->Lookup(y)...

与

convert_to_proxy(GetLookup(x))->Lookup(y)...

conver_to_proxy确实返回的指针不变，除非它为NULL，在这种情况下，它返回一个FailedLookupObject，就像我的另一个答案一样。

在大多数编译器中它可能不会崩溃，因为非虚拟函数通常以“ this”为参数进行内联或转换为非成员函数。但是，该标准特别指出，在对象的生存期之外调用非静态成员函数是未定义的，并且将对象的生存期定义为在分配了对象的内存并且构造函数完成时开始（如果有）非平凡的初始化。

该标准仅对在构造或销毁过程中对象本身进行的调用提供了此规则的例外，但是即使这样，也必须小心，因为虚拟调用的行为可能不同于对象生命周期中的行为。

TL：DR：即使要花很长时间清理所有呼叫站点，我还是要用火杀死它。

在形式上未定义行为的情况下，编译器的未来版本可能会更积极地进行优化。我不会担心现有的部署（您知道编译器实际实现的行为），但是如果您使用其他编译器或不同版本，则应在源代码中对其进行修复。

这就是所谓的“聪明又丑陋的骇客”。注意：聪明！=明智。

在没有任何重构工具的情况下查找所有呼叫站点应该很容易；以某种方式破坏GetLookup（）使其不编译（例如，更改签名），以便您可以静态识别误用。然后添加一个名为DoLookup（）的函数，该函数可以立即执行所有这些黑客操作。

在这种情况下，我建议从成员函数中删除NULL检查并创建一个非成员函数

CThingy* SafeLookup(CLookupThing *lookupThing) {
  if (lookupThing == NULL) {
    return NULL;
  } else {
    return lookupThing->Lookup();
  }
}

然后，应该很容易找到对Lookup成员函数的每个调用，并将其替换为安全的非成员函数。

如果今天有事困扰您，那么一年后会困扰您。正如您所指出的那样，对其进行更改几乎肯定会引入一些错误-但您可以从保留return NULL功能开始，添加一些日志记录，让它在野外运行数周，然后查找甚至遭到攻击的次数？

您今天可以通过返回失败的查找对象来安全地解决此问题。

class CLookupThingy: public Interface {
  // ...
}

class CFailedLookupThingy: public Interface {
 public:
  CThingy* Lookup(string const& name) {
    return NULL;
  }
  operator bool() const { return false; }  // So that GetLookup() can be tested in a condition.
} failed_lookup;

Interface *GetLookup() {
  if (notReady())
    return &failed_lookup;
  // else etc...
}

该代码仍然有效：

CThingy *pFoo = GetLookup()->Lookup( "foo" ); // will set pFoo to NULL without crashing

仅当您对规范的措辞不屑一顾时，这才是“炸弹”。但是，无论如何，这是一种糟糕的建议，因为它掩盖了程序错误。仅出于这个原因，即使需要进行大量工作，我也将其删除。这不是立即（甚至中期）的风险，但这并不是一个好的方法。

这样的错误隐藏行为实际上也不是您要依赖的东西。假设您依赖此行为（即，不管我的对象是否有效，它都可以正常工作！），然后由于某种危险，编译器会优化该行为。if在特定情况下语句，因为它可以证明this不是空指针。这不仅对某些假想的未来编译器，而且对于非常实际的当前编译器，都是合理的优化。
但当然，因为没有很好地形成你的程序，它恰好有时在20个角附近将其传递为null 。邦，你死了。 诚然，这是非常人为的，并且不会发生，但是您不能100％确信它仍然不可能发生。this

请注意，当我大声喊“删除！”时，这并不意味着必须将它们全部删除。 立即或在一个大量的人力操作。您可以在遇到这些检查时将它们逐个删除（无论如何，如果您在同一文件中更改某些内容，避免重新编译），或者仅进行文本搜索（最好是在高度使用的函数中），然后将其删除。

由于您使用的是GCC，因此您可能会感兴趣 __builtin_return_address，这可能有助于您没有大量人力的情况下删除这些检查，并且完全破坏了整个工作流程并使该应用程序完全无法使用。
删除支票之前，请将其修改为输出呼叫者的地址，并addr2line告诉您源中的位置。这样，您应该能够快速识别应用程序中行为不正确的所有位置，以便可以对其进行修复。

所以代替

if(!this) return 0;

一次将一个位置更改为以下内容：

if(!this) { __builtin_printf("!!! %p\n", __builtin_return_address(0)); return 0; }

这样一来，您就可以为此更改识别无效的呼叫站点，同时仍然让程序“按预期工作”（如果需要，您还可以查询呼叫者的呼叫者）。修复每个不良行为的位置，一个接一个。该程序仍将正常运行。
一旦没有更多的地址出现，一起删除所有检查。如果不幸的话，您可能仍然必须修复一个或另一个崩溃（因为它在测试时未显示），但这应该是一件非常罕见的事情。无论如何，它应该防止您的同事对您大喊大叫。
每周删除一张或两张支票，最终将一无所有。同时，生活还在继续，没人注意到您在做什么。

TL; DR
至于“ GCC的当前版本”，您可以使用非虚拟功能，但是当然没有人可以说出将来的版本可以做什么。我认为，将来的版本不太可能导致您的代码中断。现有项目中很少有这种检查的（我记得我们有时在Code :: Blocks中确实有数百个这样的检查，不要问我为什么！）。编译器制造商可能不想让数十/数百个主要项目维护者故意不满意，只是为了证明一个观点。
此外，请考虑最后一段（“从逻辑观点出发”）。即使此检查将在以后的编译器中崩溃并刻录，无论如何它也将崩溃并刻录。

该if(!this) return;语句this在结构良好的程序中永远不可能是空指针（这意味着您在空指针上调用了成员函数），因此该语句有些用处。当然，这并不意味着它不可能发生。但是在这种情况下，程序应该崩溃或断言。在任何情况下，此类程序都不应默默继续。
另一方面，完全有可能在碰巧不是null的无效对象上调用成员函数。检查是否this空指针显然不能捕获这种情况，但它是完全相同的UB。因此，除了隐藏错误的行为，此检查还仅检测出一半的问题案例。

如果您按照具体的措辞行事，则使用this（包括检查是否为空指针）是未定义的行为。在严格意义上讲，这是“定时炸弹”。但是，我不会合理地无论从实际角度还是从逻辑角度认为这个问题。

• 从实际的角度来看，只要您不取消引用指针，是否读取无效的指针就无关紧要。是的，严格按照字母，这是不允许的。是的，从理论上讲，可能有人会构建一个CPU，该CPU将在加载无效指针时对其进行检查并出错。las，如果您是真实的，情况并非如此。
• 从逻辑的角度来看，假设检查会爆炸，那么仍然不会发生。为了执行该语句，必须调用成员函数，并且（是否为虚拟的，是否为内联的）使用的是invalid this，它可以在函数体内使用。如果一种非法使用this炸毁，另一种也会。因此，由于程序早已崩溃，检查已被废弃。

我个人认为，您应该尽早失败以提醒您遇到问题。在这种情况下，我会毫不客气地删除if(!this)我能找到的每一次出现。