在C / C ++中检查NULL指针[关闭]

在最近的代码审查中，贡献者试图强制NULL以下列方式执行对指针的所有检查：

int * some_ptr;
// ...
if (some_ptr == NULL)
{
    // Handle null-pointer error
}
else
{
    // Proceed
}

代替

int * some_ptr;
// ...
if (some_ptr)
{
    // Proceed
}
else
{
    // Handle null-pointer error
}

我同意他的方法在某种意义上更为清晰，因为它明确地说“确保此指针不为NULL”，但我要反驳这一点，说的是从事此代码工作的任何人都将理解在指针中使用指针变量。if语句隐式检查NULL。我也觉得第二种方法引入类似漏洞的可能性较小：

if (some_ptr = NULL)

这只是查找和调试的绝对痛苦。

您喜欢哪种方式，为什么？

以我的经验，首选形式为if (ptr)或的测试if (!ptr)。它们不依赖于符号的定义NULL。他们不会暴露意外指派的机会。而且它们清晰而简洁。

编辑：正如SoapBox在注释中指出的那样，它们与C ++类兼容，例如auto_ptr，这些对象充当指针，并提供转换以bool完全启用此惯用语。对于这些对象，与的显式比较NULL必须调用对指针的转换，该转换可能具有其他语义副作用，或者比bool转换所暗示的简单存在检查更为昂贵。

我偏爱没有不需要的文本的代码，它表示什么意思。if (ptr != NULL)具有与之相同的含义，if (ptr)但以多余的特异性为代价。下一个合乎逻辑的事情是写作if ((ptr != NULL) == TRUE)，那就是疯狂。C语言清楚的是一个布尔通过测试if，while或类似的具有特定的非零值意思是真和零是假的。冗余无法使其更加清晰。

if (foo)很清楚。用它。

我将从这一点开始：一致性为王，决策不如代码库中的一致性重要。

在C ++中

在C ++中，NULL定义为0或0L。

如果您已经阅读了C ++编程语言 Bjarne Stroustrup建议在进行赋值时0明确使用以避免NULL宏的方法，我不确定他是否在比较中也做了同样的事情，因为阅读这本书已有一段时间了，我认为他只是做了if(some_ptr)没有明确的比较，但是我对此感到模糊。

这样做的原因是该NULL宏具有欺骗性（几乎所有宏都是如此），它实际上是0文字的，而不是顾名思义的唯一类型。避免宏是C ++中的常规准则之一。另一方面，0看起来像一个整数，当与指针进行比较或分配给指针时则不是。就我个人而言，我可以选择任何一种方式，但通常我会跳过显式比较（尽管有些人对此不满意，这可能就是为什么您有贡献者建议进行更改的原因）。

不管个人感觉如何，这在很大程度上都是最不邪恶的选择，因为没有一种正确的方法。

这很清楚，是一个常见的习惯用法，我更喜欢它，在比较期间没有偶然赋值的机会，它的内容很清楚：

if(some_ptr){;}

如果您知道这some_ptr是指针类型，则很明显，但它也可能看起来像是整数比较：

if(some_ptr != 0){;}

这是清晰的，在通常情况下是有道理的...但是它是一个泄漏的抽象，NULL实际上是0字面意义，最终可能容易被滥用：

if(some_ptr != NULL){;}

C ++ 0x具有nullptr，由于它明确且准确，现在是首选方法，请小心意外赋值：

if(some_ptr != nullptr){;}

在您能够迁移到C ++ 0x之前，我会担心这是浪费时间，因为您担心使用的是哪种方法，它们都不够用，这就是为什么发明nullptr的原因（以及完美的转发所带来的通用编程问题） 。）最重要的是保持一致性。

在C中

C是另一只野兽。

在C中，可以将NULL定义为0或（（void *）0），C99允许实现定义的空指针常量。因此，它实际上归结为实现的NULL定义，您将必须在标准库中对其进行检查。

宏非常常见，并且通常会大量使用宏来弥补语言和其他方面的通用编程支持方面的不足。语言更简单，对预处理器的依赖更加普遍。

从这个角度来看，我可能会建议NULL在C中使用宏定义。

我使用if (ptr)，但这完全不值得争论。

我喜欢我的方式，因为它简洁明了，尽管其他人说它== NULL使它更易于阅读和更明确。我知道他们来自哪里，我只是不同意使事情变得简单的多余东西。（我讨厌宏，所以我有偏见。）由您决定。

我不同意你的说法。如果您没有收到有条件分配的警告，则需要提高警告级别。就那么简单。（出于对所有美好事物的热爱，请不要切换它们。）

请注意，在C ++ 0x中，我们可以做到if (ptr == nullptr)，对我来说确实读得更好。（再次，我讨厌宏。但是nullptr很好。）if (ptr)尽管如此，我仍然这样做，只是因为这是我的习惯。

坦白说，我不明白为什么这么重要。任一个都非常清楚，并且任何对C或C ++有一定经验的人都应该两者都理解。不过，有一条评论：

如果您打算识别错误并且不继续执行该函数（即，您将引发异常或立即返回错误代码），则应使其成为保护子句：

int f(void* p)
{
    if (!p) { return -1; }

    // p is not null
    return 0;
}

这样，您可以避免“箭头代码”。

就我个人而言，我一直使用if (ptr == NULL)它，因为它使我的意图明确，但在目前，这只是一种习惯。

使用=代替==将任何主管编译器正确的警告设置捕获。

重要的一点是为团队选择一个一致的风格并坚持下去。不管您采用哪种方式，您最终都会习惯它，并且欢迎在使用他人代码时失去摩擦。

仅支持该foo == NULL做法的一点：如果foo是a int *或a bool *，那么if (foo)读者可能会意外地将支票解释为测试pointe的值，即as if (*foo)。NULL这里的比较提醒我们，我们在谈论指针。

但是我想一个好的命名约定会使这种论点失去意义。

实际上，我使用两种变体。

在某些情况下，您首先检查指针的有效性，如果指针为NULL，则仅从函数中返回/退出。（我知道这可能导致讨论“一个函数应该只有一个出口点”）

大多数时候，您检查指针，然后执行所需的操作，然后解决错误情况。结果可能是带有多个if的丑陋的x倍缩进代码。

C编程语言（K＆R）会让您检查null == ptr，以避免意外分配。

如果样式和格式将成为您的评论的一部分，则应该有一个公认的样式指南作为参考。如果有，请按照样式指南的指示进行操作。如果没有，则应在编写时保留此类详细信息。这是浪费时间和精力，并且分散了代码审查真正应该发现的内容。严重的是，如果没有样式指南，我原则上将尽量不要更改这样的代码，即使它不使用我喜欢的约定也是如此。

但这并不重要，但我个人的喜好是if (ptr)。对于我来说，这个含义比甚至更显而易见if (ptr == NULL)。

也许他是想说最好在错误的路径之前处理错误情况？在那种情况下，我仍然不同意审稿人。我不知道对此有一个公认的约定，但是在我看来，在任何if语句中，最“正常”的条件应该放在首位。这样，我就不必花太多时间去弄清楚该功能的含义和作用方式。

例外情况是，如果错误导致我无法使用该功能，或者可以继续进行操作，则可以从中恢复。在这些情况下，我确实会先处理错误：

if (error_condition)
  bail_or_fix();
  return if not fixed;

// If I'm still here, I'm on the happy path

通过预先处理异常情况，我可以解决它，然后再忽略它。但是如果我不能通过预先处理而回到幸福的道路上，那么应该在以后处理在主要情况因为这会使代码更易于理解。在我看来。

但是，如果它不在样式指南中，那么这只是我的观点，您的观点同样有效。要么标准化，要么不标准化。不要仅仅因为评论者有意见就让其伪标准化。

这是两种语言的基础知识之一，指针将评估为可bool在C ++和C中用作控件表达式的类型和值int。只需使用它即可。

• 指针不是布尔值
• 当您if (foo = bar)意外编写时，现代C / C ++编译器会发出警告。

所以我更喜欢

if (foo == NULL)
{
    // null case
}
else
{
    // non null case
}

要么

if (foo != NULL)
{
    // non null case
}
else
{
    // null case
}

但是，如果我正在编写一组样式准则，则不会在其中添加类似的内容，而会在其中添加以下内容：

确保对指针进行空检查。

我是一个事实，即C / C ++不检查类型在布尔条件一个巨大的风扇if，for和while语句。我总是使用以下内容：

if (ptr)

if (!ptr)

即使是整数或其他转换为bool的类型：

while(i--)
{
    // Something to do i times
}

while(cin >> a >> b)
{
    // Do something while you've input
}

这种编码方式对我来说更具可读性和清晰度。只是我个人的意见。

最近，在使用OKI 431微控制器时，我注意到以下几点：

unsigned char chx;

if (chx) // ...

比

if (chx == 1) // ...

因为在以后的情况下，编译器必须将chx的值与1进行比较。其中chx只是一个true / false标志。

我使用过的大多数编译器至少会在if没有进一步语法加糖的情况下警告分配，因此我不购买该参数。就是说，我既专业，也没有偏好。== NULL虽然在我看来，这个绝对清晰。