if(self = [super init]) - LLVM 警告！你是怎么处理的？答案

【问题标题】：if(self = [super init]) - LLVM warning! How are you dealing with it?if(self = [super init]) - LLVM 警告！你是怎么处理的？
【发布时间】：2011-02-09 01:03:37
【问题描述】：

在带有 LLVM 的 Xcode 4 之前，编译器不会注意到这一点。条件句中的赋值是完全有意的，是 Cocoa 的习语。

选择 LLVM 编译器的 Xcode 4 永远不会抱怨，不仅仅是在编译时，一旦你输入它，黄色警告图标就会出现。将警告作为错误关闭并忽略警告似乎不是一个好主意。将赋值移出括号会浪费空间。必须为每个新项目使用编译指示关闭此警告将变得乏味。

你是如何处理它的？新的成语会是什么？

【问题讨论】：

格式化代码时，“浪费空间”不一定是真的浪费。缩进行以反映程序结构“浪费空间”，但你不这样做吗？
相对于只为自己分配/评估的习语浪费空间。我非常关心代码看起来有多密集，并且在它使事情更清晰时根本不介意额外的行。
爱双重否定的 JeremyP。
我刚刚注意到，从 Xcode 5.1.1 开始（至少），您现在可以只使用一对括号，但警告仍然不会出现。我想知道幕后发生了什么......

标签： iphone objective-c llvm xcode4

【解决方案1】：

这实际上是一个非常古老的警告，它在 GCC 和 Clang 1.6 中默认关闭。 Xcode 实际上应该为您提供如何修复它的建议 - 即，将括号加倍。

if ((self = [super init])) { ... }

额外的一对括号告诉编译器您确实打算在条件中进行赋值。

【讨论】：

确实如此 - 我只是假设我知道它在抱怨什么，所以我没有阅读工具提示。

【解决方案2】：

如果您从较新的 Xcode 文本宏创建 init 方法，您会注意到执行 init 的新方法是：

- (id)init {
    self = [super init];
    if (self) {
        <#initializations#>
    }
    return self;
}

这样可以避免警告。虽然我个人在我自己的代码中遇到这种情况，但我只是在应用 Kevin 展示的方法。

好消息！

【讨论】：

不完全确定你可以称之为新的“祝福方式”。 Apple 在编码风格上一直不一致。
我不是说以前的样式没有一次也被祝福过……在计算中，没有祝福是永远的。所以也许它更像是一种“魅力”。
凯文和肯德尔的答案都是有效的。它们之间的区别在于 Kendall 会检查超类的初始化是否有效。 Aaron Hillegass 在他的书中解释说，如果超类的初始化失败，一些初始化器将返回 nil。我的印象是这种情况是病态的（运行时失败），这就是为什么似乎没有任何在返回 nil 的情况下重试初始化的例子。不过，我在这里超出了我的深度，只是在推测这一点。我希望看到权威的深入解释。
我的答案和 Kevins 之间在功能上没有区别，他们都检查是否创建了超类 - 他只是将作业包装在 if 中，这是我提供的代码的简写版本。最主要的是 LLDB（正确地）在 if 子句中对赋值有警告，所以我们只有两种方法来解决警告，两种方法都有效......

【解决方案3】：

只需使用两对括号，让编译器清楚您是故意分配的：

if ((self = [super init]))

【讨论】：

【解决方案4】：

打开项目导航器并选择您的项目。在出现的主窗口中，选择“全部”。在“LLVM 编译器 2.0 - 警告”部分下，选择“其他警告标志”。为“Debug”和“Release”添加标志“Wno-idiomatic-parentheses”。现在清理并重新编译。

【讨论】：

【解决方案5】：

正如其他一些人建议的那样，您应该添加一组额外的括号。

我远不是正则表达式专家，所以请随意清理它，但 Xcode 中的查找和替换修复了大约 95% 的实例：

Replace: if\s*\({1}\s*self\s*={1}(.*)\){1}
With:    if ((self =\1))

要小心，因为这也会找到 if (self == ...)，所以使用预览并取消选中这些或修复我的正则表达式 :)

然后开始使用 self = ...; if (self)，它更干净。

【讨论】：