PageControl 示例代码中的警告：使用赋值结果作为不带括号的条件
我试图了解 UIPageControl 的工作方式。所以我从苹果下载了这个示例代码 UIPageControlSampleCode 它运行良好，但在以下代码中的 if 语句处有一个警告（使用赋值的结果作为不带括号的条件）：
- (id)initWithPageNumber:(int)page
{
if (self = [super initWithNibName:@"MainView" bundle:nil])
{
pageNumber = page;
}
return self;
}
现在我的问题是：开发人员为什么要这样做？在 if 语句条件内进行赋值？这是一个错误吗？
I'm trying to understand the way UIPageControl works. SO I downloaded this sample code from Apple
UIPageControlSampleCode
It runs fine but there is a warning (Using the result of an assignment as a condition without parentheses) at the if-statement in the following code:
- (id)initWithPageNumber:(int)page
{
if (self = [super initWithNibName:@"MainView" bundle:nil])
{
pageNumber = page;
}
return self;
}
Now my question is: why would the developer do something like this? making an assignment inside of an if-statement condition? Is it a mistake?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
赋值运算符 (=) 除了执行赋值之外，还返回指定的值。这样你就可以做类似的事情，
对于编译器来说与编写相同
这意味着在做时
你可以通过将赋值放在 if 语句中来检查 init 是否成功。如果成功，它将返回一个有效的指针，该指针不为零，这意味着 if 语句的条件为 true。如果 init 失败，它会返回 nil，实际上为零，因此继续其余的初始化是没有意义的。
发出警告的原因是很容易在 if 语句中意外使用 (=) 而不是 (==)：
因此编译器会尽力保护您免受此错误的影响。
因此，我更喜欢在您的示例中明确条件：
An assignment operator (=), except for performing the assignment, also returns the assigned value. This is so you can do stuff like
Which for the compiler is the same as writing
This means that when doing
You can check if the init succeeded by putting the assignment in an if statement. If it succeeded it returns a valid pointer, which is not zero which means the condition of the if statement is true. If the init fails, it returns nil which is actually zero, so there is no point in continuing the rest of the initialization.
The reason for the warning is that it's easy to accidentally use (=) in an if statement instead of (==):
So the compiler is trying to protect you from this mistake.
For this reason I prefer making the condition explicit, in your example:
此警告是因为自从 Apple 创建示例代码以来，编译器的版本和默认编译器选项已发生更改。
特别是，这个警告 - 告诉您您可能意味着“==”而不是“=”（因为该语句处于“if”条件，并且您通常测试相等而不是赋值） - 非常符合逻辑；但是在以前版本的编译器和 Xcode 中默认情况下不会激活警告，这解释了为什么此类代码可能仍然存在于旧的示例代码中（没有人是完美的，甚至是 Apple 开发人员； ））。
正确的正常用法/约定是：
if (nil != (self = [super initWithNibName:@"MainView" bundle:nil]))if ((self = [super initWithNibName:@"MainView" bundle:nil]))也可以工作并删除警告。我建议采用第一种解决方案。
如果你显式地测试，在赋值之后，赋值的结果（因此
self中的值）不为 nil，那么当你读取代码时（即使它不是你的），你就是确定意图是什么。如果您以这种方式保留代码（并保留警告），即使代码可以工作，此警告也可确保您没有在代码中错误地输入“=”而不是“==”，因为这可能是常见错误（对于新手来说，对于经验丰富的程序员来说也可能打字太快;））所以我认为现在激活它是一件好事，并且为了清楚起见，显式与 nil 进行比较是一个很好的做法< /em>
This warning is because since the sample code have been created by Apple, the version of the compiler and the default compiler options have changed.
Especially, this warning -- that tells you that you may mean "==" instead of "=" (because the statement is in a "if" condition and you generally test for equality instead of assignation) -- is quite logic; but the warning wasn't activated by default in previous versions of the compiler and of Xcode, which explains why such code may still be present in old sample codes (nobody's perfect, even Apple developpers ;)).
The correct normal usage/convention is then:
if (nil != (self = [super initWithNibName:@"MainView" bundle:nil]))if ((self = [super initWithNibName:@"MainView" bundle:nil]))will work too and remove the warning.I would suggest to adopt the first solution.
If you explicitly test that, after the assignation, the result of the assignation (thus the value in
self) is not nil, then when you read the code (even if it is not yours), you are sure of what was intended.Even if the code will work if you keep the code this way (and keep the warning), this warning ensures that you didn't mistype '=' instead of '==' in your code, as this may be a common mistake (for newbies but also for experienced programmers that may have typed too fast ;)) so I consider it being a good thing that it is now activated, and a good practice to explicitly make the comparison with nil for the sake of clarity