Указатели, правильно ли я их использую?Objective-C / какао - PullRequest
2 голосов
/ 02 апреля 2010

У меня есть это в моем @ interface

struct track currentTrack;
struct track previousTrack;
int anInt;

Поскольку это не объекты, мне не нужно иметь их как int * anInt, верно? И если устанавливать необъектные значения, такие как ints, boolean и т. Д., Мне не нужно освобождать право на старое значение (при условии, что среда не GC)?

Структура содержит объекты:

typedef struct track {
NSString* theId;
NSString* title;
} *track;

Я правильно это делаю?

Наконец, я получаю доступ к структуре следующим образом:

[currentTrack.title ...];
currentTrack.theId = @"asdf"; //LINE 1

Я также вручную управляю памятью (из установщика) для структуры, подобной этой:

[currentTrack.title autorelease];
currentTrack.title = [newTitle retain];

Если я правильно понимаю сборку мусора, я смогу отказаться от этого и просто установить его как LINE 1 (выше)?

Кроме того, при сборке мусора мне не нужен метод dealloc, верно? Если я использую сборщик мусора, значит ли это, что он работает только на OS 10.5+? И еще что-то, что я должен знать перед тем, как перейти на сборщик мусора?

Извините, вопросов так много. Очень плохо знакомы с Objective-C и настольным программированием.

Спасибо

Ответы [ 3 ]

4 голосов
/ 02 апреля 2010

У меня есть это в моем @ interface

struct track currentTrack;
struct track previousTrack;
int anInt;

Так как это не объекты, мне не нужно иметь их как int* anInt верно?

Это объявило бы указатель на int, хранящийся в другом месте.

А если установить необъектные значения, такие как ints, boolean и т. Д., Мне не нужно освобождать правильное старое значение (при условии, что среда не GC)?

release - это сообщение. Вы можете отправить сообщение только объекту Какао (или, в некоторых случаях, Базовому фундаменту).

Структура содержит объекты:

typedef struct track {
    NSString* theId;
    NSString* title;

Точнее, содержит указатели на объекты.

Вы не можете хранить объект непосредственно в переменной; Вы можете выделить его только динамически, отправив alloc сообщение классу и получить указатель на выделенный экземпляр. Точно так же вы можете только отправить сообщение на указатель на объект; Вы не можете и не должны разыменовывать указатель на объект.

По этим причинам мы почти всегда исключаем «указатель на». Мы говорим об указателях, как будто они являются объектами, но, по правде говоря, они не являются.

} *track;

Это правильно, если вы хотите объявить тип track как указатель на struct track. Как правило, это смущает людей.

Наконец, я получаю доступ к структуре следующим образом:

[currentTrack.title ...];
currentTrack.theId = @"asdf"; //LINE 1

Итак, предыдущая строка - строка 0? ;)

Я также вручную управляю памятью (из установщика) для структуры, например так:

[currentTrack.title autorelease];
currentTrack.title = [newTitle retain];

Если я правильно понимаю сборку мусора, я смогу отказаться от этого и просто установить его как LINE 1 (выше)?

Если вы используете сборщик мусора, то сообщения autorelease и retain ничего не сделают, так что да, простое назначение и назначение с (неэффективными) сообщениями release и keep эквивалентны.

Я задаю вопрос, почему вы помещаете эту информацию в структуру, а не в объект модели .

Также с сборкой мусора мне не нужен метод dealloc, верно? Если я использую сборщик мусора, значит ли это, что он работает только на OS 10.5+? И еще что-то, что я должен знать, прежде чем перейти на сборщик мусора?

Да: прочитайте Руководство по программированию сборки мусора . Он расскажет вам все, что вам нужно знать, включая ответы на два предыдущих вопроса.

Что касается указателей, вы можете прочитать учебник по моим указателям . Название говорит C, но все в C также верно в Objective-C.

2 голосов
/ 02 апреля 2010

Несмотря на то, что вы, кажется, в целом все понимаете, я настоятельно рекомендую не хранить объекты в структуре. Получение надлежащего управления памятью для этого будет очень проблематично - потому что, хотя сама структура не требует управления памятью, объекты все еще нуждаются в ней, и если к структуре не когда-либо обращаются только через API функции (по существу, это делает ее объектом бедняков) вам будет трудно убедиться, что это произойдет. Как сказал Питер, имеет смысл быть модельным объектом.

0 голосов
/ 02 апреля 2010

Правильно, правильно, нет, да, правильно, да, и Руководство по программированию сборки мусора от Apple - хорошее чтение.

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