Reference-counting пойнтеры избавляют от утечек?
Чтобы отстрелить ногу наверняка, надо смешать в одном приложении reference-counting и GC, и дать ему нагрузку.
есть еще вариант строить систему на auto_ptr + weak_ptr.
классы в качестве полей имеют право содержать auto_ptr только для отношения родитель-ребенок, во всех остальных случаях должен быть weak_ptr
ps
такую штуку можно даже статически верифицировать на отсутствие колец.
классы в качестве полей имеют право содержать auto_ptr только для отношения родитель-ребенок, во всех остальных случаях должен быть weak_ptr
ps
такую штуку можно даже статически верифицировать на отсутствие колец.
auto_ptr is deprecated in favour of unique_ptr in C++11, между прочим!
однофигственно. в unique_ptr лишь move явно надо делать, а в auto_ptr он делался не явно.
Странный вопрос. Утечка памяти - это баг, и, независимо от выбранного метода управления жизненным циклом объектов, у тебя может быть баг, который приведет к утечке памяти, например, считаешь референсы, а unref забыл вызвать.
у тебя может быть баг, который приведет к утечке памяти, например, считаешь референсы, а unref забыл вызвать.Да, помню, в COM это было обычное дело.
а unref забыл вызвать.а потому что его явно надо вызывать только в особых случаях и, соответственно, проверить все тышшу раз!
Kowai! 
например, считаешь референсы, а unref забыл вызвать.Ну типа, это обязанность QSharedPointer в данном случае.
или забывание отписываться от событий в .NET'е 
Чтобы отстрелить ногу наверняка, надо смешать в одном приложении reference-counting и GC, и дать ему нагрузку.Питон под нагрузкой? Нет, не слышал.
Питон под нагрузкой? Нет, не слышал.подкинь что ли ссылок тогда?
пока я нагуглил что в питоне как раз refcounting, дополненный cycle detector
Maybe some day a sufficiently portable automatic garbage collector will be available for C. Until then, we’ll have to live with reference counts.
Видимо у нас разное понимание gc: http://www.digi.com/wiki/developer/index.php/Python_Garbage_...
Питон под нагрузкой? Нет, не слышал.Разве gc в приложениях с большой нагрузкой не принято отключать?
Разве gc в приложениях с большой нагрузкой не принято отключать?Большой нагрузке большая память!
Разве gc в приложениях с большой нагрузкой не принято отключать?Не знаю о таком.
У них до версии 2.7 GC запускался раз в константное, а не пропорциональное количество аллокаций (несбалансированных деаллокациями). То есть при создании дофига объектов GC жрал квадратичное время. Поэтому было принято его ваще отключать во время стартапа, и подкручивать трешхолды чтобы не особо часто вызывался при нормальном функционировании. Попробуй сделать туплу на миллион элементов и вызвать gc.get_count.
В 2.7 и позже задумываться об этом не надо, потому что он вызывается только когда активно на 25% больше аллокаций чем при предыдущем вызове.
В 2.7 и позже задумываться об этом не надо, потому что он вызывается только когда активно на 25% больше аллокаций чем при предыдущем вызове.
Я имел в виду что не знаю про "принято", а не про то что можно отключать и настраивать.
Имхо это решается индивидуально в зависимости от приложения и высокая нагрузка в терминах web тут вообще не при чем.
Имхо это решается индивидуально в зависимости от приложения и высокая нагрузка в терминах web тут вообще не при чем.
Оставить комментарий
apl13
Допустим, циркулярных зависимостей не будет.Или лучше как-то более прицельно стрелять себе в ногу?