Xcode 4/LLVM 3.0 - 使其对于“选择器没有已知的实例方法”变得更加智能错误？
下面的代码是完全安全的，但是 Xcode 4 给了我一个错误：
if ([self respondsToSelector: @selector(foo)])
[self foo];
我知道我可以使用虚拟协议来绕过它，但我经常使用这种模式，而且感觉不应该做那么多工作必要的。有什么方法可以在某处设置一个设置，最好一次，这样这个“错误”就不会再次困扰我？
The following code is perfectly safe, yet Xcode 4 gives me an error for it:
if ([self respondsToSelector: @selector(foo)])
[self foo];
I am aware that I can get around it with a dummy protocol, but I use this pattern pretty often, and it feels like that amount of work should not be necessary. Is there any way to set a setting somewhere, preferably once, so that this "error" does not bug me again?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果没有参数且没有返回值，则该表达式仅“完全安全”。如果需要任何类型信息，
@selector(foo)是不够的。即便如此，我怀疑有些架构的 ABI 是这样的，即无参数无返回情况实际上需要编译器可以使用类型知识才能生成绝对保证正确的代码。
也就是说，如果没有完整类型，您的
fooWithInteger:和/或fooWithX:y:z:示例可能不可能被正确编译由于 C 语言和特定于体系结构的 ABI 的变化莫测，信息可用。同样，要允许编译器在没有警告的情况下进行编译，需要编译器将运行时表达式 -
respondsToSelector:must 动态分派 - 与编译时表达式结合起来。编译器讨厌这样。That expression is only "perfectly safe" if there are no arguments and no return value. If any type information is required,
@selector(foo)is insufficient.Even then, I suspect that there are architectures whose ABI are such that the no-arg-no-return case would actually require that type knowledge be available to the compiler to be able to generate code that is absolutely guaranteed correct.
That is to say, your example of
fooWithInteger:and/orfooWithX:y:z:could not possibly be compiled correctly without the full type information available due to the vagaries of the C language and the architecture specific ABI.As well, to allow the compiler to compile that without warning would require the compiler to collude a runtime expression --
respondsToSelector:must be dynamically dispatched -- with a compile time expression. Compilers hate that.为了在遵循这种模式时使编译器保持沉默，我使用 -performSelector:
我不知道还有其他方法。
To silence the compiler when following that kind of pattern, I use -performSelector:
I don't know of any other way.