Быстрый доступ к map по ключу строке

Пример конфига в статье это JSON

Быстрый доступ к map по ключу строке

Спасибо за наводку.

Быстрый доступ к map по ключу строке

Добавил для сравнения тот же код только с unordered_map новый пример а под MaC Os производительность с unrodered_map получилась даже на 5% хуже. А про колизии я говорил только в случае если хранить в качестве ключа только хэш.

Быстрый доступ к map по ключу строке

Во первых в вашем случае нужно чтобы экземпляр TEventStorer был доступен из той же единицы трансляции, в заголовочном файле экземпляр объявить нельзя получим ошибку на этапе линковки. Поэтому придется делать некий синглтон и метод его получения. Мой вариант со статическими методами и static гарантирует что на этапе сборки в код попадет только один инстант шаблона для каждого типа. Далее половина моего кода это всего навсего безопасный тип, на скорость выполнения не влияющий. зато помогает найти ошибки еще на этапе компиляции. Если убрать из моего кода типобезопасность и дополнительные методы то получается 15 строк

Быстрый доступ к map по ключу строке

Да соглашусь пример не очень удачно иллюстрировал случай когда использование данного приема оправдано, заменил в статье на новую ссылку новый пример. Сразу уточню содержимое events заранее не известно, потому как в реальности поимо логики в коде сам класс Script тоже може добавлять туда элементы, так же не известны ни eventIds, ни список событий на который реагирует данный объект. Поэтому харанее включить указатель или ссылку на сущности не получится. Также на практике возможно укладывать в events сразу EventType так как во многих случаях он известен на этапе создания программы.

    if(some_condition)
    {
        static EventType::Type some_type = EventType::find("some_id");
        events.push_pack(some_type);
    }

В новом примере прирост производительности где-то около 3-х раз, если у вас есть мысли как сделать тоже самое проще или быстрее буду очень благодарен за совет.

Быстрый доступ к map по ключу строке

Да идея похожа слегка но служит немного другим целям, тем не менее программисты хотят поиск по int, а геймдизайнеры строковые ключи в конфигах.

String enum — строковые enum

единственная возможность оптимизации это ф-я tolower но на макросах этого сделать я не смог а constexpr не поддерживает даже 2013 MSVC(только November 2013 CTP of the Visual C++ Compiler)
к тому же всетаки поиск по map сравним по скорости даже с преобразованием строки в число, поэтому скорость парсинга конфигов почти такая же как с цифрами.

String enum — строковые enum

char* str = mp.toParam<me>();

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

String enum — строковые enum

идея конечно в целом хорошая но чтобы сделать запись компактной все равно придется оборачивать ее в макросы
и к тому же

    const char* value = "one";
    MyEnum me = mp.toEnum<value>();
    char* str = mp.toParam<me>();

не компилируется а мне это не подходит, потому как именно эту строку я считываю из конфига, на этапе компиляции она как раз не известна.

String enum — строковые enum

Пробовал не получилось к сожалению, если есть идея как это сделать без макросов буду очень признателен за подсказку.

String enum — строковые enum

Кросс-язычность не нужна нужна кросс-платформенность а этот код собирается под всеми системами Windows — MinGW & MSVC 2013, Mac Os X & iOS — XCode(clang), Android GCC4.8+ Clang 3.2+

String enum — строковые enum

Открою страшный секрет: конфиги в геймдеве пишут люди и в основном для людей, и как раз читаемость первична. Если конфигов много и их загрузка занимает порядочное время, то их можно как то обрабатывать. Был у меня проект где весь мир был в конфигах ~ 15mb XML далее скриптами делалось 2 выгонки для сервер и для клиента. Далее еще по ним проходился другой скрипт и удалял все что можно(пробелы табы неиспользуемые поля и тд). Но если проект не столь масштабен то читаемость на первом месте.

String enum — строковые enum

Плюсы решения
1 — простота синтаксиса (синтаксис похож на обычным enum)
2 — минимум кода (столько же сколько объявить обычный enum)
3 — возможность сделать итерироваться по значениям enum
4 — скорость работы (при мапе из 20 элементов скорость поиска в 6 раз выше чем std::map<string,int> и в 3.5 раза std::unordered_map<std::string,int>)
5 — отсутствие зависимостей(кроме std::string std::map)
6 — возможность использовать switch (что тоже положительно сказывается на скорости)
7 — возможность приведения имен строк к нижнему регистру STRING_ENUM( MyStringEnum, ONE, TWO, THREE); в строку будет преобразовано как «one», «two», «three»
8 — типобезопасность

Минусы
1 — Шаблонная магия
2 — 32 элемента максимум

пример относительно скорости ideone.com/1HNGIe