K
Вам и не нужно представлять все символы. Только валидные для идентификаторов, а они зачастую не выходят за границу 16 бит)
А комментарии и строковые литералы?
Size: a a a
2020 December 01
h
Пожалуй мне стоит в этой теме получше разобраться. А то не понятно кому из вас верить
M
А комментарии и строковые литералы?
Про стороковые литералы я ничего не коворил, но в компиляторе вы их все равно будуту представлять как абстракный массих данных. Мы сейчас говорим про формат для символов токенов / идентификаторов и таблицы симворов верно?
K
Ну так у нас строки являются частью сырца, на который мы потом ссылаемся.
K
Хотя можно взять UTF-8 и на этапе лексера получить указатели на спан, а не индексы
h
Ну так у нас строки являются частью сырца, на который мы потом ссылаемся.
да и с комментариями тоже также...
Правда есть одна большая проблема с этим: ютилитивные комменты — док комменты, например, которые возможно обрабатываются встроенным модулем для доков
Правда есть одна большая проблема с этим: ютилитивные комменты — док комменты, например, которые возможно обрабатываются встроенным модулем для доков
K
Сделать под них отдельные лексемы
M
Ну так у нас строки являются частью сырца, на который мы потом ссылаемся.
И что? Если IDE или редактор умеет выводить UTF16 то и USC-2 отобразит, они совместимы. В противном случае преобразуем UTF16 в UTF8, но это не проблема, верно? Куда лучше это делать для диагностике нежели каждый раз декодировать UTF-8 симпол в codepoint на каждый чих
M
Еще раз вычислить длину для UTF-8 это O(N) задача, если она не закеширована, а если стоки мутабельны то это практически всегда и гарантированно придется делать. Что бы достать n-й символ из UTF-8 нужно его декодировать - это довольно недешевая операция. Для UCS-2 это O(1) и никакой амортизации при доставании символа соответственно)
M
Да: в 2 раза больше места нужно для латиницы, зато дял не-латиницы обычно выходит даже меньше. Туту как всегда копроммис между памятью и скоростью
YS
Еще раз вычислить длину для UTF-8 это O(N) задача, если она не закеширована, а если стоки мутабельны то это практически всегда и гарантированно придется делать. Что бы достать n-й символ из UTF-8 нужно его декодировать - это довольно недешевая операция. Для UCS-2 это O(1) и никакой амортизации при доставании символа соответственно)
А зачем lexer-у, и впоследствии тому, что будет обрабатывать лексемы, доставать n-й символ из UTF-8, и вычислять его длину?
M
Yaroslav Schekin
А зачем lexer-у, и впоследствии тому, что будет обрабатывать лексемы, доставать n-й символ из UTF-8, и вычислять его длину?
Для валидации как минимум
YS
Для валидации как минимум
Валидации чего?
M
например тому, что все символы для идентификаторов соответствуют таблице совместимости
YS
Привествую всех,не могу понять зачем к токену всегда добавляют запись из таблицы символов,вдруг токен описывает какой то оператор или операцию? (это написано в книге про компиляторы,где дракон нарисован 2 издание)
А где там написано, что добавляют именно запись из таблицы символов (вроде же, описывалось сохранение лексемы для каждого token)?
M
Yaroslav Schekin
А где там написано, что добавляют именно запись из таблицы символов (вроде же, описывалось сохранение лексемы для каждого token)?
Это уже как реализуешь. Можно эту валидацию делать на уровне лексера, а можно на уровне парсера в самом начале
M
В книге дракона этот момент может быть вообще упущен для упрощения
YS
например тому, что все символы для идентификаторов соответствуют таблице совместимости
Это проверит или lexer посимвольно, или parser (так же), или уж следующий этап.
И на каждом следующем после lexer этапе уже есть лексема... В общем, я так и не понял. :(
И на каждом следующем после lexer этапе уже есть лексема... В общем, я так и не понял. :(
t
книга с драконом,она поверхностно рассказывает детали компиляции ,книга Keith Cooper Linda Engineer Compiler и после нее Advanced Compiler Design and Implementation дадут полную картину понимания процесса компиляции ?
t
или стоит прочитать дракон,а потом перейти к этим книгам (: