Кто нибудь знает constexpr реализацию state-mashine? Ну типа есть токены "true",false,Истина,Ложь,Да,Нет... И

нужно реализовать парсинг и отдать token-id
?

Что значит "constexpr реализация"? Она должна в компайлтайме пробежаться по состояниям в зависимости от какой-то константы?

Ну задаешь список токенов, а оно само строит state-машину. Как то...

Всё ещё не понимаю, что это за токены и как это относится к стейт машине. Звучит как парсер какой-то заданной грамматики. Если я нагадал на кофейной гуще верно, то может помочь boost.spirit.x3

Пусть есть допустимый набор строк "мама", "мыла", "раму". Нужно вернуть соответственно 0,1,2 или Ош скажем -1 если что то не то. Без лишних телодвижений. Набор строк произволен и задаётся в коде. Если набор строк неоднозначен - не компилируется с умным сообщением.

То есть, тупо constexpr мапа?

std::array не подходит?

Возможно, но реализацию смотреть надо. Есть?

https://github.com/serge-sans-paille/frozen

Крутая штука. Но они используют bits::binary_search<N>(items_.begin().... То есть бинарный поиск по сортированному массиву. В случае строковых ключей он всегда начинает с начала строки. Я и сам так могу. То есть надо - если мы съели "м", то перешли в состояние 2 где у нас варианты только "ама" и "ыла". И если следующий символ "а", то наше состояние только "ма" или ошибка. С каждым символом область допустимых значений должна сжиматься.

Всё ещё не понимаю задачу. Почему, например, не подходит тупо consteval int str_id(std::string_view view) { if (view == "мама") return 1; if (view == "мыла") return 2; if (view == "раму") return 3; return -1; }

Так не consteval нужен, а ран-тайм. При consteval мне (практически) без разницы сколько оно думает. А в рантайме сравнение каждый раз идёт с начала. То есть "мама" и "мыла" начинаются с буквы "м". Соответственно оптимальный алгоритм выглядит switch(ch) case 'm': goto state_m ... state_m: switch(ch) case 'а' case 'ы' .... А вот эти switch-case я хочу в компиле-тайм построить

префиксное дерево построить хочешь?

https://userver.tech/d9/dbf/classutils_1_1TrivialBiMap.html

это разве не в рантайме?

Там все функции constexpr помечены, если что

и что?

Так constrexpr != consteval. Constexpr может и в runtime, и в compiletime.

Стоит, как минимум, подумать (а лучше измерить) даст ли это хоть какое-то ускорение по сравнению с нормальной небранчующейся хэш-функцией. Например, CityHash.

Ну зайди посмотри генерируемый асм, я не знаю. Или доклады актуальные от Полухина посмотри, тоже узнаешь. Спойлер: компилятор генерирует префиксное дерево

/// constexpr utils::TrivialBiMap kToInt = [](auto selector) { return selector() .Case("zero", 0) .Case("one", 1) .Case("two", 2) .Case("three", 3) .Case("four", 4); }; /// Это по мотивам llvm StringSwitch. У меня такое есть. Для десятка кейсов пофиг. А для 1500 тяжко

там 99% кодогена не будет, а будет хождение по глобальному массиву

Там кодген

ну кинь годболт

Сам зайди и убедись

куда заходить

ахуеть

Констэкспр и в рантайме работать может

Я сам делал и убеждался, что там компилятор хорошо оптимизирует. А еще я верю тому, что написано в документации: utils::TrivialBiMap and utils::TrivialSet are known to outperform std::unordered_map if: • there's 32 or less elements in map/set • or keys are string literals and all of them differ in length. Implementation of string search is very efficient due to modern compilers optimize it to a switch by input string length and an integral comparison (rather than a std::memcmp call). In other words, it usually takes O(1) to find the match in the map. The same story with integral or enum mappings - compiler optimizes them into a switch and it usually takes O(1) to find the match. Если ты фома неверующий - это твоя проблема

switch by string length

Компилятору явно виднее, в каких случаях это лучше, чем прямое префиксное дерево

но кодогена там итого нет

Если ты фома неверующий - это твоя проблема

Что-то вроде такого не пойдет? https://github.com/hanickadot/compile-time-regular-expressions https://github.com/cmargiotta/e-regex

Дойдиье годболта плиз

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

в зависимости от конкретных данных и железа, оптимальный алгоритм также может выглядеть как "взять gperf либо аналог"