LINUX.ORG.RU

История изменений

Исправление alysnix, (текущая версия) :

Тормозит не только сам std::shared_ptr

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

А теперь о серьезном. Сколько косвенных адресаций в std::shared_ptr? Сдается мне, что две. А заглядывать в этот, простите, не самый красивый код в stdlib не охота.

одна. сам shared_ptr показывает на контрольный блок, в котором уже физический поинтер. и счетчик ссылок. и счетчик слабых ссылок. еще и деаллокатор.

Что получается? Раст выигрывает даже на меньшем уровне косвенности у плюсов. А если код однопоточный, где можно использовать Rc вместо Arc, то раст выигрывает у плюсов еще и за счет того, что нет атомиков.

вот и прошу написать то же самое на расте. чтобы один раз увидеть.

у нас в деревне никто раста не знает, потому сам не можу.

Исходная версия alysnix, :

Тормозит не только сам std::shared_ptr

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

А теперь о серьезном. Сколько косвенных адресаций в std::shared_ptr? Сдается мне, что две. А заглядывать в этот, простите, не самый красивый код в stdlib не охота.

одна. сам shared_ptr показывает на контрольный блок, в котором уже физический поинтер. и счетчик ссылок. и счетчик слабых ссылок. еще и деаллокатор.

Что получается? Раст выигрывает даже на меньшем уровне косвенности у плюсов. А если код однопоточный, где можно использовать Rc вместо Arc, то раст выигрывает у плюсов еще и за счет того, что нет атомиков.

вот и прошу написать то же самое на расте. чтобы один раз увидеть.

у нас в деревне никто раста не знает, потому сам не можу.