Как стать автором
Обновить

Комментарии 16

Когда-то подобным образом автоматически генерировал С++ интерфейсы из xml спецификаций D-Bus. С помощью утилиты qdbusxml2cpp.
Мы делаем ещё хитрее: у нас ряд функций ПО выносится в выполнение в отдельных процессах (a-la chromium). Сделано не столько из-за соображений безопасности, сколько из-за нестабильности ряда сторонних компонентов. Отдельный привет здесь передаю реализации Mico ORB :)

В удалённых модулях пишутся классы для экспорта через D-Bus, из них генерируются XML-файлы с описанием с помощью утилиты qdbuscpp2xml, для вызывающей стороны из этих XML генерируются классы интерфейсов через qdbuscpp2xml.

Главная проблема, на которую сейчас напоролись — QtDBus ужасно тормозит на передаче больших (порядка 1-2 Мб) блобов через шину. На девелоперской машине (Core i7-2600K) на блоб весом в 2 Мб уходит порядка секунды :(
Чем создание классов скриптом отличается от ручного копипастинга? Такой же быдлокод по сути. Кодогенерация оправдана только там, где результата нельзя добиться нормальным способом, или где она дает прирост производительности. Не говоря о том, что для 100 сгенерированных классов каждый метод будет сгенерирован в 100 экземплярах (что здорово раздует размер бинарника). Надо применять нормальный ООП-подход или наследование. не все, правда, это умеют.
>>Чем создание классов скриптом отличается от ручного копипастинга?
Скоростью. Меньшей ценой ошибки (всегда можно перегенерить всё)

>>Кодогенерация оправдана только там, где результата нельзя добиться нормальным способом, или где она дает прирост производительности
Извините, это полная ерунда. Нет такого кодогенератора который напишет лучше чем программист руками. Никакой кодогенератор не сгенерить более производительный код чем опытный программист

>>Надо применять нормальный ООП-подход или наследование.
Кодогенерация не отрицает ООП и наследование, даже наоборот.

Кодогенерация оправдана там, где нужно писать много рутинного бессодержательного кода. При работе с базами данных это действительно актуально.
Не верите мне — почитайте Фаулера, например, «Шаблоны корпоративных приложений»

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

Об этом лучше подумать сейчас, потом будет поздно.
Да, я прекрасно осознаю что это решение, которое потом невозможно исправить. Поэтому я придумал снизить риск путем выноса бизнес-логики в плагины. Сам движок приложения будет лишён бизнес-логики, будет работать по правилам описанным в XML. Однако для описания поведения декларативный XML не очень годится. Нужен полноценный язык. Возможно, еще изменю решение в пользу QScript, он показывает неплохую производительность кстати. Либо бинарный плагин со скриптом внутри.
Кодогенерация — это априори грабли при портировании, особенно если для неё нужна специальная утилита, которой может не быть на целевой платформе. При кросскомпиляции так вообще кодогенератор все может колом накрыть если кодогенерацией занимается не утилита конфигурирования и сборки.
Никто особых проблем с тем же moc и uic не испытывает. Кодогенератор можно на самом Qt написать для лучшей портируемости
Там хитрости идут некоторые, но вообще иметь секас со сборкой проги по одной спеке а утилит по другой обеспечен. Хотя qbs тут в принципе готов зверски помочь, ибо можно будет кодогенератор просто плагином для qbs собрать и подгрузить.
Не вижу особой разницы — подгрузить плагин или выполнить консольную команду. С командой даже проще в том плане что можно взять готовую, а плагин еще написать придется.

Впрочем QBS штука интересная, заслуживает. Но пока она экспериментальная — пользуемся qmake'ом.
На CMake делается без проблем. Можно делать так, что исходные файлы для одной из целей проекта будут генерироваться утилитой, собираемой вместе с проектом в рамках другой цели. Он сам разрулит зависимости и установит правильный порядок сборки.

Проверено на людях :)
Не в этом сложность. Тебе нужно собирать софт для винды, в процессе сборки у тебя генерится утилита, в случае кросскомпиляции нужно заставить её для платформы хоста скомпилить, что малость непонятно как сделать. Форсить платформу? Но как?
Реализуемо, хоть и затруднительно. Как такое на qmake сделать — не знаю, но я с ним вообще довольно поверхностно знаком, необходимости не было :)

У нас в принципе не стояло задачи сделать поддержку кросс-компиляции. Мы же здесь ведём речь о бизнес-приложениях, для них такая цель вообще ставится редко (у нас платформа сборки вообще по большому счёту одна).
А я ожидал генерации исходников средствами лишь qmake'а… Да, сторонние утилиты портят картину.
Но всё равно — спасибо за статью!
Вы меня натолкнули на мысль собирать кодогенератор во время сборки целевого проекта :) Но это уже достойно блога «Ненормальное программирование»
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории