Dealloc NSString вызывает сбой - PullRequest
0 голосов
/ 15 марта 2019

Я работаю над приложением Objective-C. Там у меня есть этот фрагмент:

QString result;
NSString *tmp = nil;
tmp = [activeApp bundleIdentifier];
result = QString::fromNSString(tmp);
NSLog(@"activeApplicationBundleId 2");
if (tmp) {
    NSLog(@"dealloc");
   //[tmp dealloc];  // <--- this causes crash
}
else {
    NSLog(@"do not dealloc");
}
return result;

Я не понимаю, почему он падает. Я проверил документацию от Apple, и bundleIdentifier является свойством, определенным с копией

@property(readonly, copy) NSString *bundleIdentifier;

Я также прочитал, что должен отвечать за освобождение строки. Почему это сбой? Если я использую вместо:

NSRunningApplication* activeApp = [[NSWorkspace sharedWorkspace] frontmostApplication];
return QString::fromNSString([activeApp bundleIdentifier]);

Будет ли у меня утечка памяти из-за отсутствия освобождения строки NSString?

На всякий случай QString :: fromNSString

QString QString::fromNSString(const NSString *string)
Constructs a new QString containing a copy of the string NSString.

Заранее спасибо

1 Ответ

1 голос
/ 15 марта 2019

Во-первых, все это не имеет значения и не должно быть там, если вы находитесь под ARC.Итак, давайте предположим, что вы не используете ARC и выполняете ручное управление памятью:

  • по соглашению, вы не владеете строкой NSStt, возвращенной bundleIdentifier, поэтому вам не следует пытаться освободитьэто *

  • , даже если вы владеете строкой, вы должны освободить ее с вызовом release, а не dealloc.release уменьшит счетчик сохранения и вызовет dealloc только если счетчик сохранения станет равным нулю.Как правило, вы никогда никогда не вызываете dealloc напрямую;это может привести к освобождению объекта, на который все еще ссылаются, откуда-то еще, что может привести к повреждению памяти и серьезному падению

*) Атрибут copy определения свойства вводит в заблуждение;он описывает, что происходит, когда новое значение присваивается свойству.Поскольку свойство публично объявлено как readonly, это раскрывает детали реализации, которые не должны быть в общедоступном определении в заголовке (лучше было бы в расширении частного интерфейса, не публично видимом).Не стесняйтесь подать отчет об ошибке в Apple, который никогда не будет привлекать внимание.

...