Comments 12
может проблема что:
арахнофобы, вопреки распространённому мнению, «практически не осознают иррационального механизма собственных страхов»
То есть, в каждый экземпляр advisor_ratings_window мы положили поле bstring128 - строку с именем типа.
Выглядит тяжеловато...
Если делать чисто в compile-time, то поля в классе не будет и при итерации по экземплярам по имени типа не добраться
https://godbolt.org/z/oGd9fh1Ko
Но затраты на имя типа в экземпляре можно свести к минимуму, чисто до одного указателя
https://godbolt.org/z/YfT6a8bs3
Суффиксы-префиксы видимо так не отрежешь, придётся делать это в ран-тайме, уже при использовании имени.
пока наметки, надо подумать про совсем constexpr решение, тогда и строки эти будут гдето в статик памяти лежать.
Я ещё подумал, зачем отдельно advisor_window и advisor_window_t
Оказалось, оправдано. Чтобы итерироваться по коллекции, нужен базовый нешаблонный класс.
https://godbolt.org/z/d9chnPrhj
но в релизной сборке rtti планируется отключать, так что этот вариант не подходит
сами создаем себе на ровном месте трудности, чтобы потом их героически решать...
Нет, игродев и игровые движки, и ещё много какого софта живут без rtti. Это довольно затратный механизм, к тому же не стандартизированный. Так что в какой-то момент для тяжёлых приложений его выключают
абсолютно стандартизированный механизм
в мало-мальски существенную затратность верится с большим трудом
И зря не верите, вот недавний доклад на cppconf https://cppconf.ru/en/archive/2023/talks/78b5f3ed70594c5a86690c7351a3b383/?referer=%2Farchive%2F2023%2Fschedule%2Fdays%2F , в моей студии решение заточенное под классы движка. Все это позволяет освободить 3-4% перфа, что поверьте очень немало. Для игры это почти 0.5 свободных мс на каждом фрейме ;)
а можно узнать, сколько раз на кадре вы вызывает RTTI, а самое главное -- ЗАЧЕМ его вызывать в таких количествах
там больше расходов не на вызов, а то что стандартный механизм rtti использует два и более (msvc) хопа по пойнтерам, что плохо сказывается на данных в кеше. А используется rtti почти везде, например кастинг к нужному типу объекта (Actor -> Player, Actor -> Monster), ну это самое простое. Компонентная система, которая может иметь очень большую вложенность, вы же не заставите дизайнеров работать с ограничениями только изза того, что программисты не смогли в перф? Что еще... сериализация данных, рефлексия свойств акторов и аттачей, хранение стейта объекта. Может еще чтото забыл
это вызывается тысячи раз на кадр? через механизмы а-ля dynamic_cast?
вполне и даже больше, типовая сцена 30-40 ентитей, у каждого обвеса с чайлдами тоже около 30, нож, пушка, аутскин, системы зрения, слуха, ики, аи, которая использует BT c нодами аля блупринты. Так что я думаю даже поболе нескольких тысяч. Добавьте физику Physx, который дублирует всю сцену но уже в своих объектах
Гарри Поттер и имя типа в компайлтайм