CODEWITHSUNDEEP
objective-cnullnsobjectrespondstoselector
ma11hew28
ma11hew28

Reputation: 126487

Objective-C: Why check nil before respondsToSelector:?

I've seen code like:

if (delegate != nil && [delegate respondsToSelector:@selector(doSomething)]) ...

But, sending a message to nil just returns nil (which evaluates to NO), so why not just do:

if ([delegate respondsToSelector:@selector(doSomething)]) ...

Is the former faster if delegate == nil? Either way, I prefer the latter cause it's less code.

And, less is better than more. Every Unix pro knows that.

Upvotes: 30

Views: 4860

Answers (3)

Coleman S
Coleman S

Reputation: 498

objc_msgSend, the function used to send dynamic messages in Objective-C immediately checks the first argument (the message receiver) and returns if it == nil. Therefore, the only overhead of nil messaging is a dynamically-linked library function call, which is slightly more costly than an "intra-binary" function call. Overall, is one approach more efficient than the other? Compound conditional statements usually require additional branching, so the answer is indeterminable without looking at the code the compiler generates, but more importantly profiling the running program. Premature optimization is a Bad Thing™, but I congratulate you for actually considering efficiency and questioning "idioms" such as this.

Upvotes: 24

Percy
Percy

Reputation: 1057

You are correct. This is technically unnecessary overhead in Obj-C as any message sent to nil will return nil automatically. However, if you ignore the call to respondsToSelector: by first checking if it's nil, then you will skip the overhead of the respondsToSelector: call. So it would be faster, but by how much, I'm not sure.

Upvotes: 5

Aditya Vaidyam
Aditya Vaidyam

Reputation: 6267

There's a syntactical issue here- if you're sending -respondsToSelector to a nil object, it will always return nil. This is why you would do such a thing.

Upvotes: -3

Related Questions