АП
медленно и +30мб к приложению -_-
да, но что делать если хочешь иметь полную поддержку Юникода
Я плох в теории о lalr, lr, clr и тд.
Но вопрос скорее: "Все ли парсеры прыгают назад?"
Size: a a a
2020 December 01
А
все парсеры заглядывают вперед и на основании этого решают, что делать дальше. самым эффективным хватает заглядывания на один токен
h
все парсеры заглядывают вперед и на основании этого решают, что делать дальше. самым эффективным хватает заглядывания на один токен
у меня так и было. пока не появились проблемы с переносами строк -_-
казалось бы проблема простая, но у меня-то лайн-фиды это ж еще и семисы)
казалось бы проблема простая, но у меня-то лайн-фиды это ж еще и семисы)
TS
правда icu можно пострипать хорошо
а можно ссылку куда посмотреть где вы так делаете?
АП
а можно ссылку куда посмотреть где вы так делаете?
думаю без самостоятельной компиляции из исходников не обойтись
M
На сколько я помню та на свмом сайте есть примеры и иструкции для кастомной сборки
E
ога, для снижения массы данных там тула https://unicode-org.github.io/icu/userguide/icu_data/buildtool.html
E
+ есть режим trace в котором вы запускаете свой апп, делаете разные движения,а потом смотрите какие именно данные из ICU брались
E
ну и надо статически линковать icu в ваш апп, а не динамик
TS
+ есть режим trace в котором вы запускаете свой апп, делаете разные движения,а потом смотрите какие именно данные из ICU брались
отлично, спасибо!
2020 December 02
h
Довольно прикладной вопрос: неужели c++ компиляторы не умеют в частичную компиляцию?
Например, изменил одну букву в стринг литерале, он не может понять, что только это нужно заменить? Или есть какие-то тонкости, которые эту возможность убивают? Или может тогда компиляция становится очень сложной и долгой, и быстрее будет почти всегда просто скомпилировать как обычно?
Например, изменил одну букву в стринг литерале, он не может понять, что только это нужно заменить? Или есть какие-то тонкости, которые эту возможность убивают? Или может тогда компиляция становится очень сложной и долгой, и быстрее будет почти всегда просто скомпилировать как обычно?
VA
Довольно прикладной вопрос: неужели c++ компиляторы не умеют в частичную компиляцию?
Например, изменил одну букву в стринг литерале, он не может понять, что только это нужно заменить? Или есть какие-то тонкости, которые эту возможность убивают? Или может тогда компиляция становится очень сложной и долгой, и быстрее будет почти всегда просто скомпилировать как обычно?
Например, изменил одну букву в стринг литерале, он не может понять, что только это нужно заменить? Или есть какие-то тонкости, которые эту возможность убивают? Или может тогда компиляция становится очень сложной и долгой, и быстрее будет почти всегда просто скомпилировать как обычно?
Предположу, что повторяющиеся литералы превращаются в одно упоминание — различие, которое нельзя выявить без полной рекомпиляции.
BD
У UTF-8 буквы потенциально разной длины, до 5 байт, вроде, так что просто
str[i] а-ля C не прокатит, придётся с начала строки перебиратьсейчас до 4, ограничили
BD
Yaroslav Schekin
Эээ... зачем? Разве хранить адрес / указатель на начало лексемы (т.е. первый байт) и её длину (в байтах или символах) недостаточно для O(1)?
Лексема-то "посреди" символа начинаться не будет, я надеюсь.
Лексема-то "посреди" символа начинаться не будет, я надеюсь.
+
BD
Yaroslav Schekin
Эээ... зачем? Разве хранить адрес / указатель на начало лексемы (т.е. первый байт) и её длину (в байтах или символах) недостаточно для O(1)?
Лексема-то "посреди" символа начинаться не будет, я надеюсь.
Лексема-то "посреди" символа начинаться не будет, я надеюсь.
^ парсить исходник все равно придется в кодировке utf-8 если язык вменяемый (21 век)
h
Предположу, что повторяющиеся литералы превращаются в одно упоминание — различие, которое нельзя выявить без полной рекомпиляции.
Так вот меня и интересует, почему нельзя сделать первичный промежуточный этап для определения неизменного кода. То о чем вы говорите никак этому не помешает.
Если нет оптимизаций включенных, то машинный код практически выглядит, как A -> B, где A это сорс код, а B машинный.
Если нет оптимизаций включенных, то машинный код практически выглядит, как A -> B, где A это сорс код, а B машинный.
BD
Обыно валидные символы для начала и середины токена не привышают значение 65500 в codepoint метрики, это значит что вместо UTF32 вполне можно обойтись 16-bit на символ (UCS-2 кодировка)
в свифте идентификаторы-эмодзи поддерживаются
BD
Пожалуй мне стоит в этой теме получше разобраться. А то не понятно кому из вас верить
h
как всегда — спасибо
BD
К сожалению вы плохо знакомы с темой. Это не так, даже UTF16 нельзя сравнивать чкркз memcmp (во всяком случае полностью)
