>>> Но найти все указатели хранящие данный адрес в общем случае может только
>>> сборщик мусора.
>> В частном хватает std::shared_ptr<>.
> Ты сейчас говоришь про случай описанный в новости, или просто произносишь общую
> фразу о том, что иногда все эти сложности решаются при помощи
> shared_ptr?

Вот прямо сейчас я начну говорить о том, что не стоит вырезать контекст (вернул фразу, на которую отвечал).

> Если первое, то там оно не решается при помощи shared_ptr. Там память
> была освобождена, но не была отмаплена.

Значит решается другим частным случаем RAII, где освобождение всех ресурсов происходит в одной точке?

> Если второе, то да, иногда shared_ptr помогает, а иногда оказывается таким тормозом,
> постоянно сбрасывая кеши, то лучше бы его и не было.

Это понятно, особенно если он внутри косвенный и с подсчётом ссылок (что не является единственно возможной реализацией).

>> А Rust что делает? unique_ptr выполняет на этапе компиляции
> Неее... В расте есть аналог shared_ptr -- то ли Rc, то ли
> Arc, я не уверен, не знаю как себя shared_ptr ведёт в
> многопоточном окружении.

Arc, судя по соседней ветке, точно так же тормозит как и shared_ptr. Как его вообще можно сделать, что бы не тормозил?)

> Но вот аналога unique_ptr в расте нет. Есть что-то
> похожее на это, но это только если смотреть жопой и с
> большого расстояния.

Его там и не должно быть, насколько понимаю гарантии с передачей владения. Грубо говоря, unique_ptr засунули в borrow checker.

>[оверквотинг удален]
> fn main() {
>     let mut v = Vec::new();
>     bar(&mut v);
> }
> Когда на стеке оказывается стековый фрейм foo, одновременно существуют три указателя на
> этот несчастный Vec. Точнее в main он как бы и не
> указатель вовсе, он присутствует значением (в отличие от unique_ptr, который именно
> что ptr), но тем не менее это мутабельная переменная позволяющая менять
> Vec, и в стековых фреймах foo и bar в каждом по
> мутабельному указателю. Три мутабельных ссылки на одно значение!

Это без оптимизации. С оптимизацией bar() в принципе должна исчезнуть.

> Это не приводит к нарушениям гарантий раста, если подумать, но маркетингу это
> очень сложно объяснять, поэтому он продолжает говорить о том, что не
> более одной мутабельной ссылки бывает за раз.

Маркетингу стоит добавить бззворды типа control flow и data flow.)

> Ещё пачка отличий unique_ptr от положения дел в расте вызвана тем, что
> в расте move'ы просчитываются статически, в C++ они насквозь динамичны, они
> по-определению shallow copy, и хрен заставишь оптимизатор выкинуть все эти ненужные
> копирования.

В аналогичном варианте с std::vector оптимизатор плюсов всё выкидывал ещё во времена MSVC 7-й версии, но иногда приходилось его пинать и писать __forceinline.