开发者

Xcode 4/LLVM 3.0 -- make it a little smarter about "no known instance method for selector" errors?

开发者 https://www.devze.com 2023-03-25 01:09 出处:网络
The following code is perfectly safe, yet Xcode 4 gives me an error for it: if ([self respondsToSelector: @selector(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 patte开发者_开发问答rn 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?


if ([self respondsToSelector: @selector(foo)])
    [self foo];

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/or fooWithX: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.


To silence the compiler when following that kind of pattern, I use -performSelector:

if ([self respondsToSelector:@selector(foo)]) {
    [self performSelector:@selector(foo)];
}

I don't know of any other way.

0

精彩评论

暂无评论...
验证码 换一张
取 消