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

BFE>>В 98-ом я писал аналогичный указатель, только называл его MirrorPtr.
R>А почему "mirror"? Чтоб никто не догадался?
(точнее TMirrorPtr)
Потому, что это указатель на зеркало объекта. А вот зеркало объекта, TMirrorObj, хранило указатель на сам объект.
Если не станет объекта, то и в зеркале его видно не будет. Вот такое вот образное название. Я хотел назвать его TProxyPtr, но такой класс уже был для кэширования задействован (ЕМНИП).

В современных стандартных классах это, наверное, что-то вроде конструкции:

std::shared_ptr< std::weak_ptr<T> >

Только ключевой момент был в переопределении оператра ->

// Не указатель!
TMirrorObj& MirrorPtr::operator ->()
{
  assert(NULL != pointer_to_MirrorObj);
  return *pointer_to_MirrorObj;
}

T* TMirrorObj::operator ->()
{
  assert(NULL != pointer_to_object);
  return pointer_to_object;
}

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

R>>А почему "mirror"? Чтоб никто не догадался?
BFE>(точнее TMirrorPtr)
BFE>Потому, что это указатель на зеркало объекта. А вот зеркало объекта, TMirrorObj, хранило указатель на сам объект.

Да я догадался У меня то же самое практически, здесь простор для креатива не так велик. Но все же, это деталь реализации, а не главная функциональность, предоставляемая умным указателем. Класть деталь реализации в основу имени не есть хорошо, имхо. Хотя, для 90-х вполне простительно.

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

R>>>А почему "mirror"? Чтоб никто не догадался?
BFE>>Потому, что это указатель на зеркало объекта. А вот зеркало объекта, TMirrorObj, хранило указатель на сам объект.
R>Да я догадался

Вот! Значит можно догадаться. Не то что с weak_ptr. Вот если есть weak_ptr, значит где-то должен быть strong_ptr! Но нет.

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

R>>Да я догадался

BFE>Вот! Значит можно догадаться. Не то что с weak_ptr. Вот если есть weak_ptr, значит где-то должен быть strong_ptr! Но нет.

Я — плохой ориентир

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


E>Но у меня сложилось впечатление, что речь идёт о таком паттерне, что у нас есть какой-то стек.

Не-не, тут в общем случае не стек, а дерево, т.к. левая и правая ветви могут создаваться независимо друг от друга. В случае со стеком у нас получится, что ветви должны удаляться в порядке, обратном созданию, что далеко не всегда будет верно семантически.

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

E>>Но у меня сложилось впечатление, что речь идёт о таком паттерне, что у нас есть какой-то стек.

MD>Не-не, тут в общем случае не стек, а дерево, т.к. левая и правая ветви могут создаваться независимо друг от друга. В случае со стеком у нас получится, что ветви должны удаляться в порядке, обратном созданию, что далеко не всегда будет верно семантически.

Так обычно перебор дерева в глубину с откатами и откладываемыми на потом кандидатам и порождает стек. Мы в каждой вершине запоминаем state и ныряем по очереди в детей. Если находим где-то в листе, например, что-то перспективное, то
1) переносим этот вариант на другой аллокатор
2) Рассматриваем вариант, а не отсечься ли нам (просто сразу большое поддерево не рассматривать)

Например, мы строим какие-то гипотезы и рекурсивно (перебор дерева вглубь) их перебираем. Ну предположим что то, потом ещё это, потом ещё и вот-это и т. д.
И по пути мы строим список из 10 лучших найденных вариантов, например. И ещё в каждом узле имеем оценку насколько, относительно того, что в узле, лучший вариант можно построить.
Ну и как только находим вариант, который лучше, чем самый плохой в нашем списке, мы создаём копию его уже на куче, и заталкиваем в наш список. И, за одно можем подняться по нашему перебору куда-то вверх, если уже не осталось шансов построить за остаток перебора из этого узла вариант лучше худшего в списке лучших.
Тогда, соответственно отсекаем целое поддерево перебора...

В общем, если как-то описать задачу, в рамках которой возникла задача по управлению временем жизни объектов, то может у коллективного разума КЫВТа получится дать более вменяемый совет.

Пока что мой, основанный в основном на телепатии, совет состоит в том, что бы пойти на некоторый размен. Увеличить степень фрагментации памяти алгоритмом (не всё сразу разрушать, а управлять сразу пачками объектов), а те немногие объекты, кто в эту схему не вписывается, переносить на другой аллокатор.

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

С>Здравствуйте, SuhanovSergey, Вы писали:

SS>>Порядок создания и удаления в графе

С>Перепишите на Rust.

Не могли бы вы показать как пример с A, B, C выглядел бы на rust? После прочтения https://doc.rust-lang.org/nomicon/lifetimes.html не очень понятно как это обобщается на граф.

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

С>>Перепишите на Rust.
SS>Не могли бы вы показать как пример с A, B, C выглядел бы на rust? После прочтения https://doc.rust-lang.org/nomicon/lifetimes.html не очень понятно как это обобщается на граф.

Перепишите на Rust — это такой мем. Извините.
На граф оно не отображается, только на дерево.