немного схоже с Mr_F_, я не использую STL потому что иногда его нет (читай андроид ndk), у меня всего они самодельный контейнер - const array, перед использованием делаем reserve на количество елементов (делает alloc), а дальше аллоцируем из свободных - request (просто смещает индекс свободного элемента и возвращает указатель), удаления нету, если приспичило есть requestMore (делает realloc) но еще ни разу в игровом коде не понадобилось
в плане использования const array - он везде хранит объекты, если приспичило и структуры имеют переменный размер, то я храню тупо массив байт, в будущем сделаю чтобы несколько const array могли юзать внешний кусок данных, чтобы вообще все игровые данные аллочить за один раз (сейчас у меня всё же несколько аллокаций)
поинтеры хранятся только в тех местах где что-то ссылается на что-то (связи в скриптах которые выставляются в редакторе), но тут система чуть хитрее, в данных уровня (те которые из файла копируются в память) резервируется место под поинтер (собсно разный размер под 32\64 бита выходит), но вместо поинтера пишется индекс из нужного массива, после загрузки уровня игра делает link resolve, те проходится по всем классам (у меня свой RTTI, я знаю какой класс какие поинтеры по каким смещениям имеет), и заменяет индексы на актуальные поинтеры
думаю спросите что насчёт деревьев ? любое дерево можно представить линейно в виде массива, и точка
насчёт map ? бинарный поиск наше всё
насчёт динамических структур ? знаете, а они не нужны !
ps. и да, в игре всего ~50 аллокаций и ~30 живых поинтеров, 1 ВБО ! (хотя с ~50 vao), и всего 2-5 текстур, при этом это не хухры мухры, а полноценная игра с кучей мешей, с кучей скелетки (80+ анимаций), с
весьма впечатляющим количеством интерфейсов и тд