[C] m4 - с чем его едите вы?

m4 печален имхо. Слишком много заморочек на ровном месте.

m4 - ужас-ужас-ужас. Страшная штука. Удобства нулевые, читабельность нулевая. Альтернативы - cpp, boost::preprocessor

>Как часто вы пользуете m4 в своей работе?

Использовал для bash скриптов. Для С-то он зачем?

Видел библиотеку на С, в которой m4 используется по самые помидоры.

Альтернативы - cpp, boost::preprocessor

Я вот думал, что m4 можно использовать в довесок к cpp, чтобы не приходилось пользоваться boost::preprocessor, который по читаемости даёт фору mpl::string.

А зачем вообще понадобился такой серьезный препроцессор? Вроде как С обладает полнотой по Тюрингу сам по себе. ;)
Может, имеет смысл пересмотреть реализацию?

А зачем вообще понадобился такой серьезный препроцессор? Вроде как С обладает полнотой по Тюрингу сам по себе. ;) Может, имеет смысл пересмотреть реализацию?

Зависит от задач. В каких-то системах с жесткими требованиями по производительности, альтернативой может быть лишь кодогенерация на шаблонах (или на руках :-)).

Да и пересмотреть реализацию может окзаться затратно по времени.

Не приведи господь.

А зачем вообще понадобился такой серьезный препроцессор?

А если не брать в расчёт костыли, то на ум приходит имитация рефлексии, точнее автоматическое формирование данных для рефлексии по объявлениям структур/классов.

sendmail

В каких-то системах более полезным может оказаться вообще внешний кодогенератор, например, на перле.
Но я считаю, что это крайний случай. Простейшая причина - пойди заставь IDE поддерживать твои кодогенерирующие структуры, если они не являются частью языка.

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

>sendmail
в качестве блюда

как специя подойдет к обёрткам для конфигураций

> Стоит ли его использовать?

Лучше не надо.

Как часто вы пользуете m4 в своей работе?

Хвала Аллаху, автотулзы у нас закопали еще несколько лет назад. С тех пор забыл о нем как о страшном сне. Не пользую.

В каких-то системах более полезным может оказаться вообще внешний кодогенератор, например, на перле.

С этим согласен. Этот путь проще.

Но я считаю, что это крайний случай. Простейшая причина - пойди заставь IDE поддерживать твои кодогенерирующие структуры, если они не являются частью языка.

CMake? Или я тебя не понял? У меня вполне нормально в проектах используются moc (в cmake искаропки ©) и slice2cpp (из ZeroC Ice), проблем добавить ещё кодогенераторы я не вижу.

«Когда я слышу слово <<рефлексия>>, я хватаюсь за пистолет!»

Действительная необходимость в рефлексии встречается крайне редко, и, как правило, свидетельствует об ошибках дизайна.
Например, классическая задача сериализации объекта, традиционно требующая рефлексии, вообще говоря не релевантна при правильно организованных классах.

Таки чем заменили m4?

Нет, не в смысле вызова кодогенератора, в смысле исползования объектов.
Если ты используешь стандартные техники, поддерживаемые языком, IDE тебе предложит автокомплит методов, подсказку по параметрам и их типам, поиск определения и объявлениях. Всех этих возможностей ты лишаешься. Хотя это кажется не слишком нужным, задача встает в полный рост, когда ты, например, попадаешь на незнакомый тебе код и исправить в нем ошибки. И тебе надо понять, что это за класс такой MyCClass и почему оно падает в корку при вызове метода. А ни класса, ни метода ну нигде нет!

Автотулзы сменили на cmake.

А для кодогенерации используются xslt и python.

Всех этих возможностей ты лишаешься.

Только до очередного этапа генерации кода.

А для кодогенерации используются xslt

Ъ. А входой файл кодогенератора, промежуточные стадии и выход не валидируете XML Schema?

А ни класса, ни метода ну нигде нет!

Есть где-то в ${CMAKE_CURRENT_BINARY_DIR}.

А где об этом почитать можно?

«Когда я слышу слово <<рефлексия>>, я хватаюсь за пистолет!»

Мне надо было ещё упомянуть динамическую генерацию кода (байткод ВМ или код на С с последующей компиляцией и загрузкой)?

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

Ну, например, ввиду отсутствия в Java многостадийной трансляции она вместе с аннотациями позволяет реализовать систему настроек a-la Emacs (defcustom). В C или С++ такое делается отдельным кодогенератором и без рефлексии.

А какие с этим проблемы?

+------------+    +----------------+    +----------+
| Код на DSL | -> | CodeGen Py/XSTL| -> | Код на C |
+------------+    +----------------+    +----------+

Ну, как бе я на Си шарпе использую T4, на яве JET2 оно работает и очень всё простое по своей сути, но есть кое-какие проекты на Си, и там такое может понадобится, вот я и спрашиваю как там в Си с кодогенераторами дела обстоят. Так-то понятно, что хоть на самом Си генерируй Сишный же код, но будет ли оно выглядеть индустриальненько? Типа, как оно вообще делается-то по-взрослому?

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

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

А на базе чего? Можно использовать спецификацию на каком-нибудь DSL или классы обвешанные атрибутами.

кодогенераторами, компиляторами, трансляторами и виртуальными машинами

В этом ряду очень большая разница в сложности программ.

Недавно узнал, что существует gpp. Он может работать в нескольких режимах и попроще чем m4.

>Вроде как С обладает полнотой по Тюрингу сам по себе. ;)

Да ладно! Не путаешь с брейнф*ком?

Не путаю.

блин, показалось, что ты написал, что сишный препроцессор полон по Тюрингу)

Это была бы неправда :)