C препроцессор, #pragma, _Pragma

а ни к чему. это очередной пример гениальных прозрений под воздействием веществ у создателей стандартов.

Я в итоге не пойму - препроцессор что-ли предлагают вшить намертво в компилятор? Иначе как прагмы, обрабатываемые препроцессором, будут влиять на компилятор? Для этого придется отказаться от yacc - два разных парсера на yacc будут конфликтовать, по крайней мере один придется писать вручную.

>Я в итоге не пойму — препроцессор что-ли предлагают вшить намертво в компилятор?

натурально так. идиоты, фигле.

>Для этого придется отказаться от yacc

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

хотя в принципе, конечно, cpp не должен трогать прагмы — они остаются на месте и парзятся компилятором. ещё один случай так называемых умных решений и чётких абстракций. я в восторге, да.

Для серьёзных компиляторов парсеры обычно всегда руками пишутся.

> а ни к чему. это очередной пример гениальных прозрений под воздействием веществ у создателей стандартов.

я лично сталкивался с ситуацией когда _Pragma нужен. представь, что нужно определить #define так чтобы в теле подстановки была прагма. #pragma ты внутрь не вставишь. Вот и затык -- без _Pragma ты это не сделаешь.

а нафига? O_O

> а нафига? O_O

ну, например, директивы openmp прагмами задаются

привет придуркам-проектировщикам.

>>Я в итоге не пойму — препроцессор что-ли предлагают вшить намертво в компилятор? > > натурально так. идиоты, фигле.

А какие есть способы интеграции препроцессора в компилятор, написанный на lex/yacc? В частности, как заставить lex воспринимать "\\\n"("\" в конце строки) как пустое место, т.е объединять строки?

#inlcude вроде не сложно сделать - организовать стек дескрипторов и загонять туда старый дескриптор, а yyin присваивать дескриптор подключаемого.

А как #define? Читать файл, заменять макросы и пихать обратно в поток?

а як вообще мало предназначен для полезной работы. может, проще руками парзер сделать?

//капча: smoker. я как раз курю — откуда оно узнало?!

Парсер тут вообще не при чем видимо - это дело лексического анализатора. Он должен отдавать поток токенов, такой, какой получается из препроцессированного файла. То есть препроцессор нужно интегрировать в лексический анализатор - до него ничего нет. А после - уже парсер. А если директивы обнаруживать парсером, а не лексическим анализатором - тут уже с исходником(aka потоком символов) ничего сделать нельзя. Мы тогда уже работаем с потоком токенов. Вообщем думаю сначала добавить в лексический анализатор поддержку #pragma, _Pragma и #include, а дальше уже как получится. С остальным и внешний препроцессор справится.

Точнее, условную компиляцию парсером сделать можно(тупо из дерева вырезать ветвь некомпилируемую). Но вот #include - включение файла в поток символов - нужно делать на этапе лексического анализа.

Стандарт кстати и предполагает на одном из начальных этапов раскрыть #define, выполнить прагмы и рекурсивно обработать инклуды. Про условную компиляцию там ничего нет. Она делается позже. Возможно парсером(не лексическим анализатором же выражения в #if считать).

>Точнее, условную компиляцию парсером сделать можно

есть неплохой шанс запутать его нафиг кривыми токенами. в принципе в идеале то, что в некомпилируемом ifdef'е — оно вообще до парзера доходить не должно.

я лично препроцессор встраивал как раз в лексер. сканнер отсекает комментарии, лексер заодно обрабатывает препроцессинг, а парзер видит уже только то, что должен видеть.

минус: лексер сложный.

плюс: зато можно использовать внешний препроцессор не трогая парзер.

В принципе там можно сделать состояния(START etc. не помню как это в lex). То есть после #if 0(ну и любого неправильного выражения) выключать состояние NORMAL и включать состояние IGNORE, в котором лексмы #endif и #else включают снова нормальное состояние. Проблема только с вычислением выражения - как сделать? Если вручную - то жаль уже готового вычислителя в парсере.

> Парсер тут вообще не при чем видимо - это дело лексического анализатора.

парсер суть лексический анализатор.

грамматику разбирает синтаксический анализатор.

все иные варианты – common misconception.