Pull to refresh

Comments 17

И в результате С и С++ живут и здравствуют, и будут дальше оставаться основными системными языками.
Просто надо принять, что С/С++ не для перфекционизма, и кодить на них дальше.

А какими преимуществами обладает GC перед подсчетом ссылок, раз он используется довольно часто? D, CLR, JVM — лишь малая часть списка.

Если подсчет ссылок атомарен, а это нужно для многопоточности, то на каждый ref и deref нужно ставить барьер памяти, что не очень хорошо на работе кеша сказывается, фактически мы отказываемся от его преимуществ.

Плюс GC умеет с циклами работать.

Только непредсказуемость GC всё это на нет сводит. Да и если пользовать неатомарные счетчики ссылок, то оверхед от них становится ничтожным в сравнении с GC. А уж в многопоточке так и так придется барьеры делать всяческие.

Неужели так сложно прикрутить аналог ARC из objective-c от Apple? Имхо, единственная из известных мне реально работающих и удобных альтернатив GC. Оверхед добавляется, но он предсказуем — это чистка ссылок по выходу из scope, занимает всегда определенное время, без неожиданных «лагов» в стиле GC.

А чем описанное в статье отличается от ARC?

Принцип тот же, безусловно — подсчет ссылок. Суть в первой букве A: автоматическое. Используются возможности LLVM / CLANG для анализа возможных «трудных» и неочевидных случаев для «убийства» объектов — почти уверен, что таких накоплено довольно много. Зачем же изобретать велосипед, когда ARC используется в продакшене и много неочевидных штук уже «вычищено»?

Можно пример таких неочевидных случаев убийства? В статье как бы тоже не предлагают вручную крементить счётчики.

Неочевидные случаи — думаю, их хватает. Я ж не разработчик CLANG/LLVM — потому и призываю перенять их опыт.

С ходу сам могу придумать про банальные циклические ссылки: в objC с ними борются через фичу «слабые и сильные ссылки». «Автоматическое обнуление» (не самом деле — проверка жив ли объект по слабой ссылке) слабых ссылок и возможность вызова селектора над нулевым объектом — приятная особенность ObjC.
Думаю, для реальной жизни нужна всякая оптимизация — например, путем размещения некоторых объектов на стэке / регистрах, не трогая кучу. Без компилятора это сложно сделать.

Еще вспомнил — в ObjC есть тонкости в использовании ссылок на блок из самого блока — нельзя забывать помечать такую ссылку слабой.

В общем, думаю у сообщества ObjC / LLVM накоплен значительный опыт в работе с подсчетом ссылок. Чего бы его не воспринять.

Прекрасно, если воспринимают!

У меня в ObjC с ARC никогда не было неочевидных проблем — а те, что были, легко гуглились. Впрочем, утечки памяти в ARC вполне возможны, нужно довольно нормально понимать что именно ты делаешь, но, имхо, ARC на текущий день — лучшая система более-менее автоматического управления памяти (и точно — самая быстрая).

Поэтому и желаю такому интересному языку как D нормальную систему Ref counting.
UFO just landed and posted this here
Да, поддержка ARC на уровне компилятора например, дает возможность выносить циклы release «подальше» от scope в котором переменная больше не используется (например, через автоматическую расстановку autorelease pool).

Думаю, что на уровне конструкций только самого языка реализовать нормальную рабочую систему не получится. Прийдется «лезть» в компилятор.
Наконец нашел — вот тут чуть подробнее про неочевидный случай с блоками ObjC: https://habrahabr.ru/post/209076/#comment_7203718 (смотрите весь тред с комментами)
Sign up to leave a comment.

Articles