Вопрос о сохранении счета объектов в объектах, добавленных в массивы Obj-C - PullRequest
2 голосов
/ 28 февраля 2010

Я занимаюсь разработкой приложения для iPhone, и у меня возник вопрос по поводу управления памятью. Допустим, у меня есть класс с именем Company с NSNumber property(nonatomic,retain) с именем Id. Я делаю это:

Company *company = [[Company alloc] initWithId:[NSNumber numberWithInt:1]];

Идентификатор теперь должен иметь счет сохранения 1? Тогда я делаю:

NSMutableArray *array = [[NSMutableArray alloc] init];
[array addObject:company];
[company release];

Каким будет счет удержания на Id сейчас? Еще 1? Я должен добавить, что в методе dealloc в Company я делаю [self.Id release]. Проблема в том, что когда я делаю это в своем приложении и позже пытаюсь получить доступ к [[array objectAtIndex:0] Id], это выходит за рамки. С моей точки зрения, массив сохраняет компанию, и поэтому я должен иметь доступ к Id "через" массив. Это правильно?

Редактировать: Забыл сказать, что когда я удаляю [self.Id release] из Company приложение работает, если оно там, оно вылетает ...

Спасибо!

Ответы [ 2 ]

3 голосов
/ 28 февраля 2010

Во-первых, не думайте о сохранении количества в терминах определенного числа. Думайте о сохранении как о дельте; Вы увеличиваете или уменьшаете только счет сохранения.

Чтобы ответить на ваш конкретный вопрос:

Что будет рассчитывать на Id? сейчас? Еще 1? Я должен добавить, что в метод dealloc в компании я делаю [Self.Id релиз]. Проблема в том, что когда я делаю это в моем приложении, а потом попробуйте для доступа к [[array objectAtIndex: 0] Id] это выходит за рамки. С моей точки зрения просмотреть массив сохраняет компанию и поэтому я должен иметь возможность доступа Идентификатор "через" массив. Это исправить?

Счет сохранения идентификатора - это деталь реализации; NSNumber кэширует небольшое подмножество значений, и, таким образом, счет сохранения может быть некоторой величиной, совершенно не связанной с чем-либо, что вы могли бы ожидать, если бы вы рассматривали сохранение счетчиков в абсолютных значениях.

Если вы попытаетесь получить доступ к объекту после того, как вы уравновесили все остатки с выпусками, то вы не будете правильно следовать рекомендациям по управлению памятью.

Если предположить, что ваш экземпляр "company" сохраняет экземпляр NSNumber, то да, он все равно должен быть жизнеспособным. Что означает «вне области»? У вас есть ошибка во время выполнения или компилятор? Опубликуйте, если вы это сделаете.

2 голосов
/ 28 февраля 2010

Что касается вашего конкретного вопроса: да, это правильно. Массив сохраняет любой добавленный к нему объект, а экземпляр Company должен сохранять объект Id. (Кроме того, свойство должно называться id, а не Id, чтобы следовать соглашениям Какао.) Это предполагает, что вы сохраняете значение в методе initWithId: (используя self.Id или [Id retain]).

Я не вижу ничего плохого в вашем коде. Я думаю, что ошибка должна быть из-за того, что вы делаете между добавлением объекта Company в массив и попыткой доступа к нему снова. Вы говорите, что ошибка возникает после добавления строки [self.Id release]; в dealloc? Это также было бы очень странно.

Звучит так, будто вы перевыпустили объект Company или сам массив был освобожден. Не могли бы вы создать небольшой пример кода, который приводит к ошибке (вместо того, чтобы просто сказать «позже я это сделаю и ...»)?

Более общий ответ заключается в том, что вы не должны думать о том, каким может быть точное количество сохранений. Счет сохранения часто будет выше, чем вы ожидали из-за внутренней работы Какао. Вы должны следить только за тем, какие классы берут на себя ответственность за объект (например, NSArray и NSMutableArray), и в каких ситуациях ваш собственный код не должен / не должен вступать во владение объектом. Поэтому, когда вы спрашиваете, является ли количество сохраняемых единиц 1, это немного не относится к делу. Вопрос заключается в том, имеет ли какой-либо объект право собственности на данный объект.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...