Как Вы относитесь к идее не использовать в современном С++ new и delete? Т.е. для создания объекта использовать функции типа make_unique/shared, а удаляться объект будет, когда его умные указатели помрут.

Я немного обновил код, в частности добавил методы take() и переименовал тайпдефы в более простые варианты (Pointer и Holder)

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

Зачем так радикально, если на С++ можно писать так же и даже лучше .


Про дерево - отдельный разговор. Главное в умных указателях - это понятное управление временем жизни объекта. И бонусом - автоматическое "зануление" weak-указателей. Но вряд ли кто будет пихать в них автоматическое удаление из всевозможных сторонних контейнеров. Это другая задача, с другими реализациями и накладными расходами.

А "выйгрышь" можно увидеть на примере того же Car. В Вашей реализации есть утечки памяти: в main три раза выполнено new, и ни разу delete. Можете сказать, что в данном примере это несущественно, он про другое. Но, тем не менее, ситуация показательная: в Вашем варианте приходится задумываться, что и когда нужно/можно удалять, а что нельзя. Нужно удалять engine и car, и нельзя удалять engine2. Только из кода это ни фига не очевидно . Для сравнения, попробуйте в моём варианте что-нибудь сломать, случайно или намеренно (естественно кроме хаков типа delete &*ptr и пр.). Можно, конечно, набираться профессионализма в отладчике, но лучше просто писать программы, у которых вероятность сломаться намного меньше .

Через "observer" нельзя напрямую удалять объект (использовать delete observer и вариации). Как Вам такая мысль?

C++ (Qt)
Engine * Car::ReplaceEngine( Engine * engine )
{
    QMutexLocker lock(&mMutex);
    Q_ASSERT(engine && engine->GetOwner() == 0);
    Engine * old = mEngine.take();
    old->SetOwner(0);
 
    mEngine.reset(engine);
    engine->SetOwner(this);
 
    return old;
}
...
void Monitor::SetEngine( Engine * engine )
{
    QMutexLocker lock(&Car::mMutex);
    if (engine == mEngine) return;
 
    if (mEngine)
        mEngine->RemMonitor(this);
 
    mEngine = engine;
 
    if (mEngine)
        mEngine->AddMonitor(this);
}

vs

C++ (Qt)
SingleEngine Car::replaceEngine(SingleEngine engine)
{
    using std::swap;
    swap(m_engine, engine);
    return engine;
}
...
void Monitor::setEngine(const WeakEngine& engine)
{ m_engine = engine; }

Как по мне, так очень сладкий сахар получается. Вам так не кажется? Впрочем, о вкусах, естественно, не спорят .

Кстати начиная с какой-то версии плюсов это не нужно, можно просто std::swap звать, потому что теперь можно пегегружать std::swap и юзерский swap не нужен.

У нас кстати вот есть точно такой кусок кода - объекты в конструкторе себя регистрируют в глобальном кэше, при удалении дерегистрируют.
И что вы думаете? Где что удаляется хрен пойми. И да, это говно течет. Ровно потому что где что удаляется хрен пойми.

Ну то есть - вот он есть (глобальный, прости хоспаде) кэш. Он владеет объектами? Вроде бы нет, он не подчищает что осталось в деструкторе и делетов в нем нет. Но при том если объект есть в кэше, то новый создавать не надо, надо взять из кэша. А кто владеет объектами? Да хрен пойми, они тут и там запрашиваются и никто не думает ничего удалять.

И вот я типа могу заюзать shared_ptr и хранить в кэше шареды - всё чики-пуки... Кроме тех мест где таки явно зовется delete object с целью удалить их из кэша

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

Шутки шутки, никто не обещал что умные указатели не дадут выстрелить в ногу. Так-то можно сделать delete smart_ptr.get() и долго удивляться как же так вышло.
В вашем примере достаточно очевидно что проблема во временном хранилище - списке выделенных элементов.
По сути, вы итерируетесь по списку меняя его в процессе. Ну так фигли, хотите я вам такое же на std::vectorе напишу? Тоже будет падать. И будет падать независимо от того, вумные указатели в векторе или обычные.