Domanda Objective-C: Perché controllare nil prima di rispondere aSelector :?


Ho visto il codice come:

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

Ma, mandando un messaggio a nil ritorna nil (che valuta NO), quindi perché non fare semplicemente:

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

Il primo è più veloce se delegate == nil? Ad ogni modo, preferisco quest'ultima causa è meno codice.

E, less è meglio di more. Tutti i professionisti di Unix lo sanno.


27
2018-06-25 17:06


origine


risposte:


objc_msgSend, la funzione utilizzata per inviare messaggi dinamici in Objective-C verifica immediatamente il primo argomento (il destinatario del messaggio) e restituisce se è == nil. Pertanto, l'unico sovraccarico della messaggistica nil è una chiamata di una funzione di libreria collegata dinamicamente, che è leggermente più costosa di una chiamata di funzione "intrabinary". Nel complesso, un approccio è più efficiente dell'altro? Le istruzioni condizionali composte di solito richiedono un'ulteriore ramificazione, quindi la risposta è indeterminabile senza guardare il codice generato dal compilatore, ma soprattutto la profilazione del programma in esecuzione. L'ottimizzazione prematura è una brutta cosa, ma mi congratulo con te per aver preso in considerazione l'efficienza e mettere in discussione "idiomi" come questo.


22
2018-06-25 17:24



Hai ragione. Questo è tecnicamente inutile sovraccarico in Obj-C come qualsiasi messaggio inviato a nil sarà di ritorno nil automaticamente. Tuttavia, se si ignora la chiamata a respondsToSelector: prima controllando se lo è nil, quindi salterai il sovraccarico di respondsToSelector: chiamata. Quindi sarebbe più veloce, ma da quanto, non ne sono sicuro.


5
2018-06-25 17:13



C'è un problema sintattico qui: se invii -respondsToSelector a un oggetto nil, restituirà sempre zero. Questo è il motivo per cui dovresti fare una cosa del genere.


-3
2018-03-12 06:06