В данном случае это не важно и просто добавляет строку кода.
Однако, когда тип возвращаемого значения метода не является целочисленным, эта проверка может быть важной. Блин, кажется, они исправили это в ObjC 2.0.
Важно проверить nil
, когда должен быть возвращен нескалярный тип. Возьмите этот пример:
struct complex_t
{
int foo, bar, frob;
double nicate;
};
@interface Foo : NSObject {}
-(struct complex_t)complex;
@end
@implementation Foo
-(struct complex_t)complex { return (struct complex_t){-1, 2, -1, 1e14}; }
@end
int main()
{
struct complex_t c;
memset(&c, 0xFFFFFFFF, sizeof c);
c = [nil complex];
printf("%i %i %i %g\n", c.foo, c.bar, c.frob, c.nicate);
}
В этом примере наш c
, к счастью, memset имеет -1
s в каждом поле (кроме двойного, который я не совсем знаю, что он делает). Сообщения nil
действительно сбрасывают все в ноль.
Но подождите!
Просто предположим, что мы немного изменили наш main
:
int main()
{
struct complex_t c;
memset(&c, 0xFFFFFFFF, sizeof c);
[[[Foo alloc] init] complex]; // NEW LINE HERE!
c = [nil complex];
printf("%i %i %i %g\n", c.foo, c.bar, c.frob, c.nicate);
}
Теперь случается, что c
будет содержать то, что вернул [[[Foo alloc] init] complex]
, хотя возвращаемое значение технически не использовалось. ( РЕДАКТИРОВАТЬ Скомпилировано из gcc -lobjc -framework Cocoa
как двоичный файл x86_64. Ваш пробег может варьироваться в зависимости от вашей архитектуры.)
Кажется, что возвращаемое значение большого struct
, когда сообщение nil
не определено.