C++
красивые решения

Смешная шутка

посмотри как сделан moc и все вопросы отпадут.

Добавь свои атрибуты через расширения шланга. Это не так тяжело как может показаться с первого взгляда. Можешь начать свое путешествие с этой презентации.

ты хочешь D

Ещё менее красивый способ, чем патчить Clang — это самому допарсивать нужные атрибуты, зная SourceLocation у FunctionDecl.

Но учти, что Clang AST в достаточно большом смысле ReadOnly.

А задавать параметры шаблонов и использовать constexpr if не то? Или я вообще не понял о чём речь?

Но учти, что Clang AST в достаточно большом смысле ReadOnly.

а вот поясни это, пожалуйста

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

это как write-only код, только наоборот

решений именно с аттрибутами нет.

но по-моему, тебе подойдет __attribute__((pure))

подойдет, но это выглядит мерзко.

я хочу использовать C++ как человеко-читаемый DSL (чтобы потом из него генерить нечто совершенно другое)

и вот эта конструкция, «__attribute__((pure))» действительно остается в IR, но в ней из 21 буквы только 4 имеют смысл, а ещё 19% - мусор. Это как раз то, чего хотелось бы избежать.

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

смотри фокус:

#define PURE __attribute__((pure))

клевая, спасибо!

в этой презентации предлагают сделать то же самое, что в посте - запатчить Attr.td и пересобрать шланг. И потом, вероятно, всё что зависит от шланга - в моем случае это Emscripten, потому что надо собирать WASM.

это... костыли?

вот если бы экстеншены складывались в папочку plugins и просто подхватывались в момент старта шланга (обычного, не форкнутого и не патченного)

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

Хотелось бы послушать, как ты читаешь свой исходный код, чтобы оценить привычную тебе легкость и красоту. Можно на Java, не на C++.

я хочу использовать C++ как человеко-читаемый DSL (чтобы потом из него генерить нечто совершенно другое)

Взаимоисключающие параграфы. DSL должен оперировать категориями целевого домена а не подражать С++. Особенно беря во внимание что с читаемостью у С++ дела могут обстоять похуже чем с perl ...

Есть ли какие-нибудь более красивые решения?

Помещать код требующий модификации в какие нибуть «виртуальные» секции а потом модифицировать перед перенесением в реальные секции

ты хочешь D

Плюсую этому господину. Проще будет на D сгенерировать код для плюсов или на питоне.

Решено

Буду использовать вот такую конструкцию.

#define a(S) __attribute__((annotate(S)))

int a("boundary=immutable") main()
{
    cout << "Hello, World!" << endl;
    return 0;
}

Проверил, что это остается в AST - пробежался курсором, нашёл.

Строки парсить.

Сам синтаксис работает и для функций, и для классов.

Source-to-source transformation, похоже, придется делать с помощью libTooling :( Про это будет отдельная серия вопросов.

Я имел ввиду писать весь код на D и генерировать код D во время компиляции. D вроде такое позволяет, раз есть реализации, которые парсят файлы и грузят из них данные во время компиляции.

Там очень много зависимостей между разными узлами и инвариантов, которые в лучшем случае покрыты assert-ами, а в худшем просто роняют компилятор где-то позже. Если изменение нетривиальное, то проще с нуля по старому AST генерировать код или новое AST.

Пример: если ты хочешь оборачивать свою функцию в другую, то у тебя во всех местах вызова полетят все указатели на decl. Если обёртка меняет тип возвращающего значения, то у тебя полетят все типы зависящих выражений. Если, не дай бог, она меняет тип со скалярного на аналогичный с переопределёнными операторами, то у тебя полетят все операции (т.к. они должны быть заменены на вызов функции-члена). Если в этом участвуют шаблоны, то проще сделать вдоль, чем получить работающее AST.

то проще с нуля по старому AST генерировать код

а это вообще возможно? Как это сделать? Из AST получить C++-файл (желательно выбросив из него мусор в виде того, что там в инклудах)

Кстати существуют специальные языки программирования для преобразования программ из одного человеческого ЯП в другой.

Пара из них изобретена автором языка Ragel. (Сам Ragel - из другой оперы)

Так мне эти «аннотации» зачем - я тоже хочу написать язык программирования, для преобразования одних языков в другие, но используя C++ с аннотациями как DSL описания трансформации :)

Нужно это исключительно в целях изучения уже готовой такой штуки - фреймворка Truffle из GraalVM.

clang-format это как-то делает.

Но я не пробовал: на этом этапе меня настолько это задолбало, что я переписывал IR (что на порядок приятнее и документированнее).

Я имел ввиду писать весь код на D и генерировать код D во время компиляции. D вроде такое позволяет, раз есть реализации, которые парсят файлы и грузят из них данные во время компиляции.

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

Там AST макросов нет, правда, как в том же Nim, потому что Уолтер Брайт против их введения так как это даст слишком много свободы и он (на мой взгляд обоснованно) опасается, что люди начнут творить на грани извращения (более чем уверен что так и будет) и в итоге получится куча кода на D который не совместим друг с другом и действительно превратит его в маргинальный язык. Язык и так довольно медленно продвигается в массы (но продвигается уверенно).

В общем то, что нужно ТС на D решается легко (свои проблемы конечно тоже есть). Если уж человек освоил libclang и может бегать курсором, то на D он смог бы намного больше с теми же усилиями. Есть интересная библиотека для построения PEG парсеров - pegged - на ней может школьник DSL сделать. Но цель я вижу у ТС конкретная и другой язык ему не подходит.

Да, это чисто учебный пример. Я на C++ хочу сделать аналог того, что уже сделано на Java с помощью run+compile time reflection и байткодовой магии. Причем на Java он работает уже достаточно хорошо, вряд ли C++ может что-то улучшить. Делается это только для того, чтобы проверить мое понимание механики работы исходного продукта, не более.

лул, вот что с людьми делает жабка. осиль gdb.

посмотрите тут https://github.com/foonathan/cppast

Нужно это исключительно в целях изучения уже готовой такой штуки - фреймворка Truffle из GraalVM.

Забудь С++ и все что с ним связано - иначе ты не получишь конечный результат вообще.

Посмотри https://woboq.com/blog/moc-with-clang.html
Это реализация moc для Qt с помощью шланга. Там аннотации делают так #define Q_SIGNAL __attribute__((annotate("qt_signal")))

всё, что в других языках делается через reflection, в С++ делается кодогенерацией на этапе сборки, например, make + самописные утилиты

*compile time reflection