Здравствуйте, Alexander G, Вы писали:

AG>>>Как вообще бороться с оверхедом на подсчёт ссылок и стоит ли?

R>>*Может* стоить. Стоит ли в конкретном случае — скажет только профайлер.

AG>Профайлер скажет. Вопрос в том, что писать до тех пор, пока профайлер не потребовался, чтобы не пессимизировать преждевременно.

Если так, то стоит, дабы не пессимизировать преждевременно.


AG>>>Кстати, в Delphi для типов, для которых подсчёт ссылок встроен в компилятор, всё просто и без увеличения уровня косвенности:

R>>Зачем при обычном вызове функции надо менять счётчик 2 раза? Разве вызывающий код может освободить счётчик до возврата из функции?

AG>т.к. переданы I и S "по значению", в самой вызывающей функции этим переменным могут присваиваться другие значения, при присвоении, как обычно счётчик ссылок правой части увеличивается, затем левой уменьшается. Для балланса необходимо это неявное увеличение/уменьшение счётчика ссылок на входе/выходе.
AG>при передаче "по константному значению" возможность присвоение переменной нового значения отсутствует.

Сделали поддержку в компляторе, и так облажались


AG>наверное, можно было бы в boost::shared_ptr предусмотреть на этот случай класс, который вёл бы себя как shared_ptr без =, reset и swap, который бы не дёргал счётчик ссылок. но у boost::shared_ptr приоритеты — корректность и единообразие, а не оптимальность и настраиваемость.

По-хорошему нужен указатель, который поддерживает одновременные обращения из разных потоков (то, что сейчас вынесено в отдельные atomic_* функции); указатель, который не поддерживает обращения из разных потоков, но поддерживает разделение объекта между потоками (текущий shared_ptr); однопоточный указатель (нет в boost), и умный указатель для передачи как параметр в функции и возвращения из функций (по сути — просто обёртка над указателем).
Тогда можно было бы точно подбирать требуемый вариант, не компромитируя единообразие синтаксиса.


AG>