安全地检查 `this` 是否为空

Question

首先，我知道在空指针上调用方法是未定义的行为。我也知道，因为这不应该发生，编译器可以（并且确实）假设this 始终为非空。

但在实际代码中，您有时会意外地这样做。通常，它没有不良影响，当然this在方法中为null，并且事情可能会崩溃。

作为调试辅助，本着及早崩溃的精神，我将assert(this != 0) 放入了一个我之前不小心调用了几次空指针的方法中。它似乎有效，但clang抱怨：

warning: 'this' pointer cannot be null in well-defined C++ code; comparison may be
      assumed to always evaluate to true [-Wtautological-undefined-compare]
    assert (this ! = 0);
            ^~~~     ~

我想知道检测this 是否为空的最佳（最不正确）方法是什么。可以优化一个简单的比较。

• 我可以对this 做一些指针运算来试图欺骗编译器，或者强制它把指针当作一个整数来处理。
• 我可以使用memcmp。
• 也许有特定于编译器的扩展说“不要优化这个表达式”？

另外一个问题是，在继承的情况下，“null”这个指针实际上可能类似于0x00000004，所以最好也处理这种情况。我对 Clang、MSVC 或 GCC 的解决方案感兴趣。

Answer 1

在 gcc 中，您可以使用 -fsanitize=null 构建。 Clang 也应该有这个选项。

来自man gcc：

       -fsanitize=null
           This option enables pointer checking.  Particularly, the application built with this option turned on will issue an error message when it tries to dereference a NULL pointer, or if a
           reference (possibly an rvalue reference) is bound to a NULL pointer, or if a method is invoked on an object pointed by a NULL pointer.

这是一个测试程序：

[ ~]$ cat 40783056.cpp
struct A {
  void f() {}
};

int main() {
  A* a = nullptr;
  a->f();
}
[ ~]$ g++ -fsanitize=null 40783056.cpp
[ ~]$ 
[ ~]$ ./a.out 
40783056.cpp:7:7: runtime error: member call on null pointer of type 'struct A'

Answer 2

首先，正如 cmets 对这个问题所指出的：请尝试使用编译器内置的消毒剂。

回答您的问题：您可以将指针转换为 uintptr_t 并比较该值。请注意，此转换是实现定义的，不能保证按您的预期工作。

以下代码在 clang 3.9 中没有优化任何内容，但在 gcc 7.0 中删除了空指针检查。 0x10是任意选择的。

struct foo
{
  void bar() {
      if(this == nullptr) {
        sink(__LINE__);
      }
      if((uintptr_t)this < 0x10) {
        sink(__LINE__);
      }
      if((volatile uintptr_t)this < 0x10) {
        sink(__LINE__);
      }
  }
};

demo

Answer 3

你应该在调用成员函数之前检查指针，而不是在它之后。

Class *object = ...;
...;
if (object) {
  object->...
}

在成员函数中检查this 是否为nullptr 只能引入调用开销，并且调用者有责任确保this 永远不会是nullptr 或悬空或野指针。 不检查 rhs 是否与赋值运算符中的 lhs 相同的原因。 （但应该确保自赋值正确工作，实现这样的运算符可能会很棘手且容易出错）

当this 为nullptr 时尝试访问成员函数或变量通常会立即使您的程序崩溃，而取消引用nullptr 实际上是一个ub。在 this==nullptr 时使用 assert(this!=nullptr) 也会立即终止您的程序，但提供比崩溃更多的信息，这也依赖于 ub。

第一个 ub 检查方法需要的工作量更少，提供的信息也更少。以前的 ub 检查方法需要更多的努力（在任何地方添加断言），但确实提供了更多信息。结果是一个权衡？

如果崩溃可以重现，我更喜欢第一个（不带断言），可以添加一些日志并快速（ O(lgn) ）找出程序崩溃的行，以及this 的事实nullptr。并找出问题所在。

如果不是这样，那么assert 可能会提供更多信息，但是在这种情况下“取消引用nullptr”是否有很大帮助？我怀疑。

因此，在我看来，正确的方法是构建一个好的日志系统，并使重现错误变得更简单。

Answer 4

根据您的编译器，它可能会积极地强制执行关于 this 是 nullptr 的 C++ 规则作为 未定义 行为。

然而，优化发布的应用程序/代码仍然需要能够优雅地处理和报告可能发生这种情况的场景；在某些情况下，它实际上可能是优化性能的有意设计的一部分（JIT 引擎 - 例如我所研究的引擎）。

在这种情况下，您需要通过清楚地告知编译器您的意图与编译器携手合作。在this 上的任何类型的演员 并试图与0 或nullptr 的任何变体进行比较将不保证可靠地工作。通常，编译器会抱怨或优化它，因为它在 optimized 构建中无效。

相反，您必须将 nullptr 测试从 this member-function 内联优化中提升出来。为此，您需要提供一个不内联的静态（非成员）函数，以便执行您需要的测试。

以下代码满足该要求。

[[gnu::noinline]] // Required for testing `this` == nullptr;else c++/clang optimizes away
static bool af_isnullptr(void* self) { return self == nullptr; }

在您的class 或struct 中，您可以按如下方式使用它：

class Example {
  void member() {
    if(af_isnullptr(this)) {
      // handle `this == nullptr` case
    }
  }
};

另见：

• C++ Core Guidelines comments
• [[gsl::not_null]] attribute意图。
• [[gsl::strict_not_null]] attribute意图。

Answer 5

使用-fno-delete-null-pointer-checks 编译器选项来允许此与空值检查。

Answer 6

也许如果你尝试assert(this != nullptr)，但我认为这也会抱怨。您可能想尝试对this 进行类型转换，然后检查该值：

int* ptr = static_cast<int*>(this);

然后与assert联系。

Answer 7

clang 警告你是对的 - 如果条件 this == 0 计算结果为真，那么你的程序已经失败并且正在暴露未定义的行为。因此，当您已经知道您的程序不能表现时，您期望 定义 行为（assert() 的正确执行），这有点奇怪。

听起来像是挂在一根绳子上，你试图在你上方剪断并再次将两端打结......

如果您想确保您的方法不会被(this == 0) 意外调用，只需将其设为virtual，它将强制转储核心。