我可以使用if（pointer）代替if（pointer！= NULL）吗？

NULL通过简单编写来检查是否存在指针是安全的if(pointer)还是必须使用if(pointer != NULL)？

您可以; 空指针将隐式转换为布尔值false，而非空指针将转换为true。根据C ++ 11标准，关于布尔转换的部分：

算术，无作用域枚举，指针或指向成员类型的指针的prvalue可以转换为type的prvalue bool。零值，空指针值或空成员指针值将转换为 false；其他任何值都将转换为 true 。类型 std::nullptr_t 的prvalue可以转换为类型的prvalue bool ; 得出的值为 false 。

是的，你可以。

• 空指针将隐式转换为false
• 非空指针将转换为true。

这是C ++标准转换的一部分，属于布尔转换子句：

§4.12布尔转换

算术，无作用域枚举，指针或指向成员类型的指针的prvalue可以转换为bool类型的prvalue。零值，空指针值或空成员指针值将转换为false；任何其他值都将转换为true。可以将std :: nullptr_t类型的prvalue转换为bool类型的prvalue。结果值为false。

是的你可以。实际上，我更喜欢使用if(pointer)它，因为一旦您习惯了它，它就更容易读写。

还要注意，引入了C ++ 11 nullptr而不是NULL。

问题已经回答，但我想补充一点。

我将始终喜欢if(pointer)而不是if(pointer != NULL)和if(!pointer)而不是if(pointer == NULL)：

• 简单，小

• 机会少写了一个bug的代码，想如果我拼错平等检查操作==与=
if(pointer == NULL)可拼错if(pointer = NULL)所以我会避开它，最好是只if(pointer)。
  _{（我在一个答案中也提出了Yoda条件，但这是不同的问题）}

• 与相似while (node != NULL && node->data == key)，我将简单地写出while (node && node->data == key)对我来说更明显的字（表明使用短路）。

• （可能是愚蠢的原因）因为NULL是宏，所以如果假设某个错误地用其他值重新定义。

显式检查NULL可能会向编译器提供您正在尝试执行的操作的提示，从而导致较少出错。

是的你可以。从C继承了隐式将值与零进行比较的功能，并且在所有C ++版本中都存在。您也可以使用if (!pointer)NULL检查指针。

空指针的相关用例是

• 重定向到更深的树节点之类的东西，该树可能不存在或尚未链接。您应该始终将其紧密封装在专用的类中，因此在这里可读性或简洁性不是什么大问题。

• 动态转换。将基类指针强制转换为特定的派生类指针（您应再次尝试避免，但有时可能会发现有必要）强制转换总是成功，但如果派生类不匹配，则将导致空指针。一种检查方法是

  Derived* derived_ptr = dynamic_cast<Derived*>(base_ptr);
  if(derived_ptr != nullptr) { ... }

  （或最好是auto derived_ptr = ...）。现在，这很糟糕，因为它将派生的指针（可能无效，即null）超出了安全防护if块的范围。这是没有必要的，因为C ++允许引入布尔变量可转换内部if-condition：

  if(auto derived_ptr = dynamic_cast<Derived*>(base_ptr)) { ... }

  它不仅更短，更安全，而且其意图也更加清楚：当您在单独的if条件中检查null时，读者会想：“好，所以derived_ptr在这里一定不能为null ...那么，为什么会它为空吗？” 单行版本非常明确地说：“如果可以安全地投射base_ptr到Derived*，则将其用于...”。

  对于返回指针的其他任何可能失败的操作，同样适用，尽管IMO您通常应避免这种情况：最好将类似boost::optional“容器”之类的内容用于可能失败的操作的结果，而不是使用指针。

因此，如果空指针的主要用例应始终以隐式cast-style的变体编写，那么出于一致性的原因，总是使用这种风格是很好的，即我主张if(ptr)over if(ptr!=nullptr)。

恐怕我不得不以广告结尾：if(auto bla = ...)语法实际上只是对此类问题的真正解决方案（模式匹配）的一点繁琐的近似。您为什么首先要强制执行某些操作（例如投射指针），然后又认为可能会失败...我的意思是，这很荒谬，不是吗？就像，您有一些食品并且想要做汤。如果果汁是软蔬菜，则将其交给您的助手来提取果汁。您无需首先查看它。当您有马铃薯时，您仍将其交给助手，但他们会用失败记录将其拍回。啊，命令式编程！

更好：立即考虑您可能遇到的所有情况。然后采取相应行动。Haskell：

makeSoupOf :: Foodstuff -> Liquid
makeSoupOf p@(Potato{..}) = mash (boil p) <> water
makeSoupOf vegetable
 | isSoft vegetable  = squeeze vegetable <> salt
makeSoupOf stuff  = boil (throwIn (water<>salt) stuff)

Haskell还提供了特殊的工具，用于在确实有严重故障的可能性时（以及在其他情况下）：monads。但这不是解释这些的地方。

^{⟨/广告⟩}

当然是！实际上，写if（pointer）比if（pointer！= NULL）是一种更方便的写方法，因为：1.它易于调试2.易于理解3.如果偶然地定义了NULL的值，然后代码也不会崩溃

是。实际上您应该。如果您想知道它是否会产生细分错误，那就不会。

正如其他人已经回答的很好，它们都是可以互换的。

尽管如此，值得一提的是，在某些情况下，您可能想使用显式语句，即pointer != NULL。

另请参阅https://stackoverflow.com/a/60891279/2463963

是的，您始终可以执行此操作，因为仅当其中的条件为真时才对“ IF”条件求值。C没有布尔值返回类型，因此当条件为true时将返回非零值，而当'IF'中的条件为false时将返回0。默认情况下返回的非零值为1。因此，两种编写代码的方法都是正确的，而我将始终喜欢第二种方法。

根据我的经验，如果您的if表达式可以重写为

const bool local_predicate = *if-expression*;
if (local_predicate) ...

这样它就不会引起警告，那么那应该是if-expression的首选样式。（我知道将旧的C BOOL（#define BOOL int）分配给C ++ 时会收到警告bool，更不用说指针了。）

“安全吗？？” 是有关语言标准和生成的代码的问题。

“这是一个好习惯吗？” 这是一个问题，该问题由任何专断的人类读者理解该语句有多好。如果您问这个问题，则表明“安全”版本对将来的读者和作家不太清楚。