objective c - Objective-C: ¿Por qué marcar nil antes de respondsToSelector:?

null nsobject

Question

He visto código como:

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

Pero, enviar un mensaje a nil simplemente devuelve nil (que se evalúa como NO ), así que, ¿por qué no hacerlo?

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

¿Es el primero más rápido si el delegate == nil ? De cualquier manera, prefiero la última porque es menos código.

Y, less es mejor que more . Cada profesional de Unix lo sabe.

Answer 1

Estás en lo correcto. Esto es una sobrecarga técnicamente innecesaria en Obj-C ya que cualquier mensaje enviado a nil devolverá nil automáticamente. Sin embargo, si ignora la llamada a respondsToSelector: primero verificando si es nil , entonces omitirá la sobrecarga de la llamada respondsToSelector: . Así que sería más rápido, pero por cuánto, no estoy seguro.

Answer 2

Hay un problema sintáctico aquí: si está enviando -respondsToSelector a un objeto nulo, siempre devolverá nulo. Por eso harías tal cosa.

Answer 3

objc_msgSend, la función utilizada para enviar mensajes dinámicos en Objective-C comprueba inmediatamente el primer argumento (el receptor del mensaje) y lo devuelve si == nil. Por lo tanto, la única sobrecarga de la mensajería nula es una llamada de función de biblioteca enlazada dinámicamente, que es un poco más costosa que una llamada de función "intra-binaria". En general, ¿es un enfoque más eficiente que el otro? Las declaraciones condicionales compuestas generalmente requieren ramificaciones adicionales, por lo que la respuesta es indeterminable sin mirar el código que genera el compilador, pero lo más importante es perfilar el programa en ejecución. La optimización prematura es una cosa mala, pero lo felicito por considerar realmente la eficiencia y cuestionar "expresiones idiomáticas" como esta.