I'm writing a Button class in Objective-C with

问题:

I'm writing a simple button class, something like this:

@interface MyButton : NSObject {
  id object;
  SEL action;
}
@property(strong) id object;
@property SEL action;
-(void)fire;
@end


@implementation MyButton

@synthesize object, action;

-(void)fire {
  [object performSelector:action];
}

@end

I get the following warning from Clang on [object performSelector:action]:

PerformSelector may cause a leak because its selector is unknown

After some research I see that selectors can belong to families which have different memory requirements. The intention is for the action to return void, so it shouldn't cause any ARC difficulties and should fit in the none family.

It looks like the relevant piece of preprocessor code I want is, or is a variant of:

__attribute__((objc_method_family(none)))

But where do I put that to tell Clang not to worry?

回答1:

In the LLVM 3.0 compiler in Xcode 4.2 you can suppress the warning as follows:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
    [object performSelector:action];
#pragma clang diagnostic pop

Thanks to Scott Thompson (about this similar question: performSelector may cause a leak because its selector is unknown) for the answer.

回答2:

Because you're dynamically assigning action, the compiler sees a possible leak with ARC. In the future, the LLVM compiler may allow you to suppress the warning. Until then, you can avoid the warning by using the runtime's objc_msgSend() instead of -performSelector:.

First, import the runtime message header

#import <objc/message.h>

Next, replace performSelector: with objc_msgSend()

    // [object performSelector:action];
    objc_msgSend(object, action);

回答3:

If you're writing new code, the best way to handle callbacks is to use blocks; they are both safer and more flexible than performSelector. See http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html .

回答4:

I use this:

[object tryToPerform:action with:nil];