Как работают регексы на utf-8?

LC_LOCALE?

Но вот UTF-8 это что-то с чем-то. Как регексы определяют где буква, а где что-то другое?

Если такие регксы имеются, то они могли быть разработаны лишь в одном месте - шестой палате психбольницы г.Дурки.

Ну а если «по делу», то нужно конвертировать строку в TCHAR * и далее использовать регексы.

Владимир

TCHAR

Удолись нах.

Удолись нах.

Наверное обидел чем-то вас?
Но мой ответ не касался лично вас.

Владимир

Еще раз, удолись нах со своим cp1251.

Еще раз, удолись нах со своим cp1251.

А причем здесь cp1251?
TCHAR - UNICODE.

Владимир

Сделай одолжение, посмотри название домена сайта.

Ну домен как домен - http://winfaq.org.ru

Сделай одолжение, посмотри название домена сайта.

С чего вы взяли, что своим ответом похвалил Windows?
Да и вообще с «ровным дыханием» отношусь к любой ОС.

Владимир

Меня не интересует готовый макрос VS, мне интересно как это оптимизируют на низком уровне.

Меня не интересует готовый макрос VS, мне интересно как это оптимизируют на низком уровне.

Подождем ответов форумчан …

Владимир

Расширь код символа до long(или long long) и будет

легко работать как с векторами

Как отличить букву от другого символа? Их же там тысячи, если не десятки.

Сравнением //КО

Обычный поиск элемента в множестве, в чём вопрос?

Если циклом перебирать каждый элемент, это будет получится очень медленно. Это вообще как-то переносится на SIMD/AVX?

Бинарным поиском ищи + скорее всего получится проверять не отдельные символы, а диапазоны

И дальше вопрос с бинарным поиском, как им с utf-8 работать? Я про него фактически и спрашиваю в треде.

Как регексы определяют где буква, а где другой символ

unicode же поделён по кодам, т.е. известно какие коды относятся к буквам, какие к символам и т.д. А вообще таблицы же. Да, весит всё это изрядно.

У букв выделенные биты?

Расширь код символа до long(или long long)

Вообще, из твоих вопросов проблемы не видно

выделенные биты

Диапазоны кодов

Регексы на utf-8 работают так же как не на utf-8, потому что конечному автомату абсолютно похрен с чем работать, просто для utf-8 он будет объёмнее.

Я кстати заметил, что Ё часто не хочет определяться как буква.

Что значит «часто»? Это понятие относится либо к периодическим, либо к вероятностным процессам. Ты ухитрился найти регулярки, которые работают нерегулярно?

Если серьёзно, то Ё может быть как одним codepoint’ом, так и комбинаций нескольких, и у них разное байтовое представление. man unicode normalization.

У символа/графемы в Unicode нет макс. длины.

Я кстати заметил, что Ё часто не хочет определяться как буква.

Для справки: в курсе, что ё не входит в диапазон [а-я]?

Но размер представления всегда конечен

В юникоде 12 версии 138 тысяч символов. Битовый массив для определения букв займет всего 17 килобайт. Используем кодпоинт как смещение в этом массиве и проверяем бит по этому адресу. Это быстро. Другое дело, что нужно много таких массивов для определения других типов символов. А еще нужны таблицы для нормализации символов из-за наличия составных символов.

хуекод

Регексы на utf-8 работают так же как не на utf-8, потому что конечному автомату абсолютно похрен с чем работать, просто для utf-8 он будет объёмнее.

Это ни о чём. Навороченные библиотеки regex-ов работают весьма занятно, и даже для ускорения могут работать в восьмибитными байтами для utf-8, когда надо сравнить от текущей позиции не «буква», а конкретная начальная подстрока, когда там всё равно сколько букв, всё равно будет в конечном итоге тут сравниваться строка байтов. Это я буквально сегодня в одной библиотеке такое поведение вырезал нафиг, так как оказалось, что в этой мешанине оптимизаций они всё равно переходят на WCHAR_T в некоторых местах и это не работает для тупого преобразования unsigned char -> wchar_t для восьмибитной кодировке, причём оно даже почти работает, пока не прогнал уйму тестов и нашел, что оно затыкается для isalpha для «вВъЪ», более того, isupper меняется с islower для твердых знаков местами. Короче - дурдом.