Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Вот это аргумент: 'Это не "как на Си"'
I>>А вот это — 'Это "как на Си"' — уже нет
I>>Браво !

EP>Врёшь же. Я конкретно сказал что контроль над временем ортогонален "как на Си".

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

I>>Настолько быстрый, как С++ это невозможно. И тем не менее джава есть в low latence. А следовательно твой
EP>Настолько же быстрый — да, вряд ли. А вот разница в десятки процентов (не считая векторизацию и т.п.) вполне достижима. Огромной ценой, но тем не менее.

То есть, в кратце, незачем выжимать сок из Сишного кода, если код на десятки процентов медленнее справляется с работой. Правильно ?

EP>>>Расшифруй.
I>>Это значит, что те же задачи решаются и в Си, за доказательством смотри полноту по тьюрингу
EP>Причём тут полнота по Тьюрингу? В данном месте обсуждаем использование ref-counting там где в этом нет необходимости, то есть для подстраховки.

Из этой самой полноты следует "в этом нет необходимости, то есть для подстраховки"

EP>При том что на нём передёргиваний счётчиков на порядки меньше. И соответственно меньше overhead'а привнесённого непосредственно подсчётом ссылок.

А в Киеве дядька.

I>>Есть куча кода написаного в тысячах контор:
I>>"Зануление счетчика, вызов деструктора, который вызывает зануление другого счетчика, который вызывает деструктор,и тд и тд"

EP>В этом плане ref-counting практически никаких тормозов не добавляет (пара лишних операций перед очисткой) — подобная каскадная очистка есть и без него.

Твоя "подстраховка", требует ресурсов. Каскадная очистка — часть этой самой подстраховки. Вместо явной логики "вычислить и освободить явно" выбираем неявную "пусть деструкторы срабатывают каскадом по цепочке, авось пронесёт"