Comments 16
Извините, по моему это нечитаемо, как то многовато локального юмора и псевдосарказма, понятного лишь избранным
Интересно, как там с производительностью OpenMW. Когда его разработка еще велась на GitHub-е, там вовсю использовалась стандартная библиотека с map-ами и dynamic_cast-ы были на каждом шагу. Интересно, как сейчас с этим обстоит дело и стоит ли оно того
std::mapиstd::setвыделяют память на каждую (каждую) вставку
а unordered_map? он вроде резервирует сколько-то заранее?
будет возвращать this, а базовый класс будет возвращать null
забавно, в своём проекте пришёл к такому же решению
стандартный мап без хаков это сбалансированное дерево, обычно красно-чёрное. Каждый элемент дерева это отдельный узел, и для каждого узла выделяется память под сам узел (value + 2–3 указателя + цвет), так что да - память выделяется отдельно при каждой вставке. Держать некий набор узлов про запас это уже отдельные хаки вендора, но например мс таким не страдает, поэтому у них самое медленное дерево. с unordered_map сложнее, там выделяется массив бакетов, но сами ноды через new, т.е. все равно аллокация будет в какомто виде. Если нужно совсем без аллокаций (условно 1 раз на создании), то надо смотреть в сторону flat_has_map, fixed_map и им подобных. Ничего этого в стд нет, flat_map есть в 23 стандарте, но насколько я видел у вендоров... их до сих пор не сделали на конец 25 года, т.е. их по факту нет... с flat_hash_map вообще беда, только сторонние либы
"который и вовсе писал ужас-ужас malloc(sizeof(IMPL_TYPE)), а потом ручками звал конструктор" - тут с лафтаймом проблем точно не будет?
Формально даже по старым стандартам проблем быть не должно, placement new начинает lifetime объекта (https://en.cppreference.com/w/cpp/language/new.html#Placement_new). Разве что с выравниванием могут быть проблемы, но по факту — в 90% систем и компиляторов всё тоже будет ок.
Добавили же на этот случай выравнивания alignas+alignof
Да, а ещё aligned_alloc, но в статье и комментарии обсуждается именно голый пример "malloc + c-tor", и вот для него формально не всё хорошо.
Более того, сегодня шаблоны используются даже на микроконтроллерах
Их, кстати, используют не от хорошей жизни, а чтобы получить тот самый полиморфизм и не платить за это, zero-cost abstraction как его в книгах называют. На большинстве контроллеров vtable хранится во flash памяти, обращения к которой очень медленные. Да, на камнях пожирнее данные кэшируются, но это только на жирных камнях.
"Проклятье пятничного коммита" и "нельзя называть билд финальным" это же не суеверия, это эмпирически подтвержденные законы природы, как закон всемирного тяготения)
Любой кто работал в разработке больше года знает: чем ближе к вечеру пятницы, тем выше вероятность, что безобидная правка в README.md сломает CI/CD и вызовет панику ядра на проде
Такс, а где рассуждения касательно Entity list (система игровых объектов построенная на наследовании + фиксированных компонентах) vs Entity Component (классика, как в юнити) vs ECS? Где рассуждения о том, как лучше подготавливать список объектов для рендера и споры "компонент рендерит сам себя или же предоставляет рендеру абстрактный набор данных для отрисовки"? Где "корутины vs таймеры vs воркеры для deferred задач"?
Интересно будет почитать ваш взгляд на тематические подходы к разработке игр
Я очень плох в плюсах, но статью все еще оценил, она клевая. Напомнило ранние статьи PVS-studio.
Мифы, суеверия и народные мудрости в разработке игр