Андреас Флёр описал подход к управлению памятью в C и C++, при котором внешний код работает не с указателями, а с handles — идентификаторами объектов. Он опирается на опыт больших C++-проектов, где множество небольших объектов, связанных smart pointers, создавало частые cache misses, фрагментацию и скрытое удержание памяти. Предлагаемая схема особенно естественна для data-oriented архитектуры, а не для сети автономных объектов, владеющих своими ресурсами.
Основная идея — сосредоточить выделение памяти внутри крупных систем: рендеринга, физики или анимации. Однотипные элементы размещаются в плотных массивах, свободные слоты используются повторно, а базовый указатель массива остаётся приватным. При создании объекта наружу выдаётся только handle. Система знает, как элементы используются, поэтому может менять их расположение, выбирать AoS или SoA, откладывать удаление ресурса до освобождения GPU и проверять допустимое число объектов.
Handle содержит индекс массива и дополнительную уникальную метку. При преобразовании в указатель код проверяет диапазон индекса, занятость слота и совпадение метки. Если старый объект удалён, а слот отдан новому, устаревший handle не пройдёт сравнение. Для разных видов handles рекомендуется заводить отдельные C/C++-типы, чтобы ошибки передачи выявлялись ещё при компиляции.
Указатель всё же иногда нужен для прямого доступа. Автор советует получать его лишь на короткий участок, не сохранять и не переносить через вызовы системных функций: удаление объекта или перераспределение массива быстро делает его недействительным. Сам handle от такого перемещения массива не страдает.
В обновлении статьи предложено хранить в каждом слоте счётчик поколения и увеличивать его при освобождении. При переполнении слот навсегда отключается, поэтому повторное использование метки не позволит старому handle случайно совпасть с новым. За безопасность приходится платить конечным числом будущих идентификаторов, хотя при 32-битных handles общий лимит достигает примерно 4 миллиардов созданий.
Handles также удобны как идентификаторы между процессами, клиентом и сервером или в сохранениях. Похожий принцип применён в sokol-gfx и модулях Oryol Gfx и Oryol Anim.