2009-12-14 3 views
3

Кто-нибудь знает, если следующий код может быть проблематичным:Objective-C: инициализировать переменную всухую

NSString *addchar = nil; 

if (case1) 
addChar = [[firstname substringToIndex:1] capitalizedString]; 
else 
addChar = [[fullname substringToIndex:1] capitalizedString]; 

Предположим, что Firstname и ПолноеИмя не нулевым или пустым. Инициализирует объект NSString и устанавливает его на «nil», вызывая некоторые возможные проблемы? Кажется, мое приложение блокируется, но только для очень немногих пользователей и только для этих пользователей, но оно не имеет ничего общего с различными строками ввода или пустыми строками. Так что я пытаюсь изолировать проблему, но я не знаю разницу между

NSString *addChar; 

и

NSString *addChar = nil; 

Спасибо.

ответ

7

Любая форма вполне приемлема. Проблема, с которой вы сталкиваетесь, находится в другом месте. Я рекомендую сделать некоторые профилирование кода с помощью инструментов, чтобы выяснить, где эта проблема возникает.

+0

Спасибо. Это разочаровывает, потому что я не могу воспроизвести проблему самостоятельно (это приложение есть у меня), и это влияет только на небольшую группу, и это не вызывает крушения ... это только зависает ... так что это не создать журнал сбоев. Поэтому я не знаю, как еще это отслеживать. Даже инженеры Apple не могут найти проблему. –

+0

Имеет ли значение, работает ли этот код в статическом методе? –

1

Здесь нет никакой разницы, так как вы не читаете addChar в своем коде. Более того, компилятор может иногда инициализировать addChar до nil для вас, если вы не делаете это явно (в зависимости от области применения объявления addChar).

См. Соответствующий вопрос в this place.

+0

Что компилятор инициализирует его не определен.На практике это будет случайный мусор. – Chuck

+0

Да, я понял, что моя формулировка не совсем понятна ... На самом деле это зависит от области действия переменной (бывают случаи, когда она гарантированно будет инициализирована). – Romain

5

Без инициализатора nil, в некоторых случаях ваша переменная может быть инициализирована мусором (что ранее было в памяти). Существуют определенные правила, касающиеся того, какие типы переменных (на основе областей, статическое хранилище и т. Д.) Инициализируются автоматически для вас, но я всегда обнаружил, что проще явно инициализировать все переменные, а не запоминать эти правила.

Это говорит о том, что в обеих ветвях вашего оператора if есть любое предыдущее значение addChar, не должно быть никакого случая, когда вы можете увидеть недопустимое значение. Но это явно не мешает мне явно инициализировать нуль, и если будущий сопровождающий приходит и меняет пути кода, вы можете обнаружить, что инициализатор сэкономит вам!

2

Вы всегда должны инициализировать значение nil, если переменная не инициализирована иначе.

Вы можете отправлять сообщения в ноль, они будут игнорироваться.

NSString * str = nil; 
NSLog(@"%@", [str description]); 

Выходы:

2009-12-15 08:59:03.352 x[11775] (nil) 

Конечно мне не нужно называть description явно, я просто демонстрирует вызов nil.

0

Теперь, когда вы используете ARC, сильные, слабые и autoreleasing переменные стека инициализируется nil:

https://developer.apple.com/library/ios/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226-CH1-SW5

Кроме того, поскольку заре времен, в ObjC переменные экземпляра инициализируются к нулю:

Are instance variables set to nil by default in Objective-C?

Смежные вопросы