Objective-C: ¿Por qué comprobar nil antes de respondsToSelector :? código

Question

que he visto así:

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

embargo, el envío de un mensaje a nil sólo devuelve nil (que evalúa a NO), ¿por qué no acaba de hacer:

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

es el anterior más rápido si delegate == nil? De cualquier manera, prefiero este último porque es menos código.

Y, less es mejor que more. Todos los profesionales de Unix lo saben.

Answer 1

objc_msgEnviar, la función utilizada para enviar mensajes dinámicos en Objective-C inmediatamente verifica el primer argumento (el receptor del mensaje) y lo devuelve si == nil. Por lo tanto, la única sobrecarga de mensajería nula es una llamada de función de biblioteca vinculada dinámicamente, que es ligeramente más costosa que una llamada de función "intrabinaria". En general, ¿es un enfoque más eficiente que el otro? Las declaraciones condicionales compuestas suelen requerir una bifurcación adicional, por lo que la respuesta es indeterminable sin mirar el código que genera el compilador, pero lo que es más importante, perfila el programa en ejecución. La optimización prematura es una mala cosa, pero te felicito por considerar la eficiencia y el cuestionamiento de "modismos" como este.

Answer 2

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

Answer 3

Aquí hay un problema sintáctico: si está enviando -responde a Selector a un objeto nulo, siempre devolverá nulo. Es por eso que harías tal cosa.