棘手的空检查和调用[关闭]答案

【问题标题】：tricky null check and invocation [closed]棘手的空检查和调用[关闭]
【发布时间】：2014-05-12 12:08:54
【问题描述】：

我发现这个样板代码经常出现在我的程序中：

if (ptr) {
  ptr->method();
}

我已经用单线代替了它（就像我在Java看到人们这样做）：

ptr && (ptr->method(), true);

从生成的机器代码的角度来看，这是一个好习惯，还是我在我的二进制文件中引入了额外的常量？来自Java 的这个“端口”可能会在我的程序中引起什么问题？

【问题讨论】：

原版更好看，更易读。
是的，但类似的代码在Java 中很常见，而Java 据说（根据某些人）比C++“更好”。
@user1095108 其他人不同意某些人。
@user743414 为什么？这个特定的示例是完全有效的（如果非常不可读）代码。当然，除非有人疯狂到让operator , 超载method() 返回的任何类型。
@Angew 如果operator&& 过载也会失败，因为kills the lazy evaluation ;)

标签： c++ null

【解决方案1】：

从生成机器代码的角度来看，这完全无关紧要。如果这两种形式中的一种更好，并且编译器的优化器无法将一种转换为另一种，则不值得称为“优化器”。

这留下了哪个更易读的问题。第一个是显而易见的。第二个将很容易花费一个多分钟的时间来解析。不好。

另请注意，第二种情况可能会在存在运算符重载的情况下引入不需要的结果。如果operator , 被method() 返回的类型重载，它将在第二种情况下被调用，而不是在第一种情况下。如果operator && 被ptr 类型重载，则第二种情况将简单地失败，因为重载的&& 不会被延迟评估。但是，这两个运算符都属于强烈反对重载的运算符。

【讨论】：

单行也比if 有优势，因为它们可以出现在c++11 的constexpr 函数中。
生成的机器码依赖于这段代码之前的代码。
@user743414 当然可以。但这几乎适用于任何代码sn-p。如果我们单独分析 OP 的 sn-p，我的答案是成立的。如果我们不这样做，我们需要知道上下文才能说什么。但就您一直提到的 UB 而言，如果 OP 的版本之一有 UB，那么两者都有。
我认为您对重载 , 运算符的评论可能值得包含在您的答案中。
@user1095108 是的，但这是一个非常特殊的情况，适用于特定的处理。就好像ptr 实际上是一种重载operator && 的类型。