Обработка таблиц против необработанных указателей против умных указателей в переполнении стека

Я читал «Архитектура игрового движка — Джейсон Грегори», и он делает заявление:

Дескриптор действует как интеллектуальный указатель во многих отношениях, но это проще
реализовать и имеет тенденцию быть менее склонным к проблемам. Ручка
в основном, целочисленный индекс в глобальной таблице дескрипторов. Рукоять
Таблица, в свою очередь, содержит указатели на объекты, к которым обращается
см. Чтобы создать дескриптор, мы просто ищем таблицу дескрипторов для
адрес рассматриваемого объекта и сохраните его индекс в дескрипторе.

Грегори, Джейсон; Джефф Ландер; Мэтт Уайтинг; Ландер, Джефф; Уайтинг, Мэтт
(2011-12-13). Архитектура игрового движка (страница D). А. К. Петерс. зажигать
Издание.

Затем он дает скелетную реализацию таблицы дескрипторов (где дескрипторы просто являются целочисленными индексами в массиве указателей). В чем я не уверен, так это в том, почему вы бы использовали таблицу дескрипторов по сравнению с необработанными указателями, если вы не планируете переместить то, на что указывают?

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

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

Может быть, я что-то упускаю, но для меня это больше похоже на выбор между «сырыми» указателями и «умными» указателями (в зависимости от конкретного случая), независимо от того, определено ли время жизни (единоличное владение) или нет.