Исправление X512, (текущая версия) :
Ну или примерно половину запросов делать холостыми (для не-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
Программисты, которым всё время надо посимвольно итерировать строки профнепригодны.
Исправление X512, :
Ну или примерно половину запросов делать холостыми (для не-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
Программисты, которым всё время надо посимвольно итерировать строки профнепригодны.
Исходная версия X512, :
Ну или примерно половину запросов делать холостыми (для не-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
Программисты, которым всё время надо посимвольно итерировать строки профнепригодны.