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

I>>>Испокон веков писали на С++, даже ОС реального времени наклепали десятками для таких случаев.
I>·>Испоконнее — pure C или даже ассемблер. Но традиция — не аргумент.
I>Ассемблер — очень смешно.
На спец-железе — не очень.

I>·>Нет гарантии и в случае с умными указателями, что освобождение заковыристого графа не нарвётся на lock или тупо будет работать долго, например, удаление одного объекта вызвало разрушение целой толпы других, gc же может съесть слона по кусочкам. А вообще есть Zing JVM и прочие RT GC. Задежка GC более 10ms — репортим баг.
I>Умный указатель это решается легко и руками.
Как? Как контролировать, что smartPtr.release() сожрёт не более N микросекунд?

I>lock — в low latency никто такое не имплементит изначально
I>"удаление одного объекта вызвало разрушение целой толпы других" -
I> а 1 в 1 как в джаве, только проблемы переносятся на GC
Да, но gc не обязан это делать всё и сразу, вместо паузы в 100ms он сделает 1500 пауз по 100us. Да, throughput может и меньше, зато latency предсказуемее.
Можно, конечно, такое же соорудить и в C++, но это будет закат солнца вручную.

I> б 1 в 1 как в джаве, если разрушение это не просто занулени, а еще небольшая логика
I> в если убрать сматрпоинтеры, что часто даже лучше чем в джаве
I>Итого — на плюсах как минимум не хуже
Да, очевидно. Ибо сама java на C++ написана.

I>GC ты вообще не контролируешь, никак и гарантии у тебя сильно хилые.
GC это те же смартпоинтеры по сути, но более строгие, а значит контроля больше.