История изменений

Ну или примерно половину запросов делать холостыми (для не-ASCII строк).

Просто запрос к дереву в текущей позиции, если не найдено, то продвигаться на один char. Холостых запросов не будет, части символов будут отсеиваться на первом ноде дерева (которое Node *nodes[256];).

Ну и зачем такие регулярки человеку, которые работает с кириллическим текстом?

Регулярные выражения с байтами работают, а не с кириллицей (у меня вообще подозрения к тем кто упоминает слово кириллица, обычно это какие-нибудь фанаты КОИ-8 или cp1251). Что вы напишете, такие выражения и будут, хоть с иероглифами или смайлами.

выполнить условие «предудущий/следующий символ символ»

Зачем? Свой велосипед текстового редактора пишете?

Приводил: Посмотрел я этот ваш Rust (комментарий)

Сферический конь в вакууме, приводите конкретные примеры желательно со ссылками на софт, а не абстрактное непонятно зачем нужное «последние 20 символов».

Или даже банально кто-то напишет простые текстовые конфиги — но на родном для пользователя языке.

Никакой специальной поддержки UTF-8 не требуется, код для ASCII будет работать без изменений, максимум дописать что ch >= 128 это часть идентификатора.

Которые, внезапно, работают на базе UCS-4. Как и ICU.

Временное внутренне представление небольших буферов, которое не важно клиенту как реализовано.

Простой текст с семантикой в UTF-16 имеет строго фиксированное число байт, даже для китайского языка.

В китайском/японском языке регулярно попадаются редкие иероглифы. Одно время из-за этого был холивар сторонников Юникода и местных кодировок (Shift-JIS) когда в Юникоде ещё не было всех необходимых символов.

Не всё так просто, например: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224

Status: RESOLVED FIXED

Видимо решились заморочиться с делением на буквы/пробельные знаки/спецсимволы для идентификаторов. Могли бы просто считать ch >= 128 частью идентификатора.

только толку от этого мало без поддержки UTF-8 со стороны пользующегося юникодными символами софта.

Какой раз повторяю что не нужная никакая специальная поддержка в большинстве случаев. Статическому/динамическому линковщику ELF нет дела какие ноль-терминируемые последовательности байт сравнивать и хешировать.

А нагибать программистов раком, заставляя итерировать UTF-8

Программисты, которым всё время надо посимвольно итерировать строки профнепригодны.

Ну или примерно половину запросов делать холостыми (для не-ASCII строк).

Просто запрос к дереву в текущей позиции, если не найдено, то продвигаться на один char. Холостых запросов не будет, части символов будут отсеиваться на первом ноде дерева (которое Node *nodes[256];).

Ну и зачем такие регулярки человеку, которые работает с кириллическим текстом?

Регулярные выражения с байтами работают, а не с кириллицей (у меня вообще подозрения к тем кто упоминает слово кириллица, обычно это какие-нибудь фанаты КОИ-8 или cp1251). Что вы напишете, такие выражения и будут, хоть с иероглифами или смайлами.

выполнить условие «предудущий/следующий символ символ»

Зачем? Свой велосипед текстового редактора пишете?

Приводил: Посмотрел я этот ваш Rust (комментарий)

Сферический конь в вакууме, приводите конкретные примеры желательно со ссылками на софт, а не абстрактное непонятно зачем нужное «последние 20 символов».

Или даже банально кто-то напишет простые текстовые конфиги — но на родном для пользователя языке.

Никакой специальной поддержки UTF-8 не требуется, код для ASCII будет работать без изменений, максимум дописать что ch >= 128 это часть идентификатора.

Которые, внезапно, работают на базе UCS-4. Как и ICU.

Временное внутренне представление небольших буферов, которое не важно клиенту как реализовано.

Простой текст с семантикой в UTF-16 имеет строго фиксированное число байт, даже для китайского языка.

В китайском/японском языке регулярно попадаются редкие иероглифы. Одно время из-за этого был холивар сторонников Юникода и местных кодировок (Shift-JIS) когда в Юникоде ещё не было всех необходимых символов.

Не всё так просто, например: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224

Status: RESOLVED FIXED

Видимо решились заморочиться с деланием на буквы/пробельные знаки/спецсимволы для идентификаторов. Могли бы просто считать ch >= 128 частью идентификатора.

только толку от этого мало без поддержки UTF-8 со стороны пользующегося юникодными символами софта.

Какой раз повторяю что не нужная никакая специальная поддержка в большинстве случаев. Статическому/динамическому линковщику ELF нет дела какие ноль-терминируемые последовательности байт сравнивать и хешировать.

А нагибать программистов раком, заставляя итерировать UTF-8

Программисты, которым всё время надо посимвольно итерировать строки профнепригодны.

Ну или примерно половину запросов делать холостыми (для не-ASCII строк).

Просто запрос к дереву в текущей позиции, если не найдено, то продвигаться на один char. Холостых запросов не будет, части символов будут отсеиваться на первом ноде дерева (которое Node *nodes[256];).

Ну и зачем такие регулярки человеку, которые работает с кириллическим текстом?

Регулярные выражения с байтами работают, а не с кириллицей (у меня вообще подозрения к тем кто упоминает слово кириллица, обычно это какие-нибудь фанаты КОИ-8 или cp1251). Что вы напишете, такие выражения и будут, хоть с иероглифами или смайлами.

выполнить условие «предудущий/следующий символ символ»

Зачем? Свой велосипед текстового редактора пишете?

Приводил: Посмотрел я этот ваш Rust (комментарий)

Сферический конь в вакууме, приводите конкретные примеры желательно со ссылками на софт, а не абстрактное непонятно зачем нужное «последние 20 символов».

Или даже банально кто-то напишет простые текстовые конфиги — но на родном для пользователя языке.

Никакой специальной поддержки UTF-8 не требуется, код для ASCII будет работать без изменений.

Которые, внезапно, работают на базе UCS-4. Как и ICU.

Временное внутренне представление небольших буферов, которое не важно клиенту как реализовано.

Простой текст с семантикой в UTF-16 имеет строго фиксированное число байт, даже для китайского языка.

В китайском/японском языке регулярно попадаются редкие иероглифы. Одно время из-за этого был холивар сторонников Юникода и местных кодировок (Shift-JIS) когда в Юникоде ещё не было всех необходимых символов.

Не всё так просто, например: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224

Status: RESOLVED FIXED

Видимо решились заморочиться с деланием на буквы/пробельные знаки/спецсимволы для идентификаторов. Могли бы просто считать ch >= 128 частью идентификатора.

только толку от этого мало без поддержки UTF-8 со стороны пользующегося юникодными символами софта.

Какой раз повторяю что не нужная никакая специальная поддержка в большинстве случаев. Статическому/динамическому линковщику ELF нет дела какие ноль-терминируемые последовательности байт сравнивать и хешировать.

А нагибать программистов раком, заставляя итерировать UTF-8

Программисты, которым всё время надо посимвольно итерировать строки профнепригодны.