A std :: tr1 :: shared_ptr для Objective C ++ на iPhone?

Question

Я в основном разработчик C ++, недавно я пишу приложения для iPhone.

Мне хорошо подходит управление памятью на iPhone, из-за ограниченности ресурсов рекомендуется использовать счетчики ссылок, а не глубокое копирование.

Одна досадная вещь в том, что мне приходится самостоятельно управлять счетчиками ссылок: alloc означает counter = 1;сохранить означает счетчик ++, релиз означает счетчик -

Я хочу написать класс, подобный shared_ptr, для Cocoa Touch, поэтому мне редко приходится самостоятельно манипулировать счетчиками ссылок.

Я сомневаюсь, что естьлюбой существующий код для этого, и я хотел бы услышать несколько советов, сегодня 5-й день, так как я начал изучать цель c

Спасибо.

Answer 1

Автоматический подсчет ссылок, появившийся в iOS 5, эффективно заставит любой указатель на объект target-c действовать как интеллектуальный указатель.Вызовы retain / release будут синтезироваться компилятором при присваивании и освобождении, если только вы явно не объявите ссылку слабой, и в этом случае они будут автоматически обнулены при освобождении объекта.

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

 smart_ptr<id> array = make_smart_ptr( [NSMutableArray array] );

 NSUInteger count = [array count];            // won't work.
 count = [array.get() count];                 // works, but yuck.
 [array.get() setArray: anotherArray.get()];  // even more yuck.

Кроме того, если ваши заголовки полны классов c ++, вам придется скомпилировать весь ваш проект в target-c ++, что может вызвать проблемы, так как target-c ++ не на 100%совместим с кодом Objective-C, и не все сторонние платформы будут работать с ним должным образом.И забудьте о том, чтобы делиться своим кодом с кем-либо еще.

Возможно, вам будет интересно сделать что-то подобное, но вы не захотите его использовать.И остерегайтесь соблазна воссоздать ваши любимые биты C ++ в Objective-C.Языки очень разные, и вы могли бы потратить на это много времени, а это не время, потраченное на изучение всего того, что вы можете сделать в Objective-C, чего нельзя делать в C ++.

Answer 2

До тех пор, пока вы сначала изучите правила управления памятью, с shared_ptr нет реальной проблемы - она ​​может помочь вам в контексте C ++, но не дает волшебным вопросам исчезнуть.
shared_ptr поддерживает пользовательский деллоокатор, поэтому следующее:

@interface A : NSObject
- (void)f;
@end

@implementation A
- (void)dealloc { NSLog(@"bye"); [super dealloc]; }
- (void)f { NSLog(@"moo"); }
@end

void my_dealloc(id p) {
    [p release];
}

// ...
{
    shared_ptr<A> p([[A alloc] init], my_dealloc);
    [p.get() f];
}

... выходы:

1010 * мычание * прощай

... как и ожидалось.

Если вы хотите, вы можете скрыть деаллокатор от пользователя, используя вспомогательную функцию, например:

template<class T> shared_ptr<T> make_objc_ptr(T* t) {
    return shared_ptr<T>(t, my_dealloc);
}

shared_ptr<A> p = make_objc_ptr<A>([[A alloc] init]);

Answer 3

Вы забыли случай 4

[4] вам нужно передать указатель на объект из метода в качестве возвращаемого значения.

Здесь вам нужно -autorelease.

Я предлагаю вам прочитать правила управления памятью и написать реальный код, прежде чем пытаться выполнить этот небольшой проект, чтобы вы могли понять, как должно работать управление памятью.

Answer 4

Вы смотрели в [object autorelease]? Возможно, это немного облегчило бы ситуацию.

Answer 5

Управление ресурсами в Какао может быть сложным: некоторые вызовы API автоматически сохраняют ссылку, а некоторые нет, некоторые возвращают объект с автоматическим освобождением, некоторые сохраняют объект.Экранируя это в классе shared_ptr, вы с большей вероятностью будете совершать ошибки.Я советую сначала пройти «нормальный» маршрут Какао, пока вы не наберетесь опыта.