Comments 14
Может, кто подскажет, как такое потеснее заинтегрировать в Visual Studio? Чтобы не создавать дополнительные файлы и номера строк для ошибок отображать.Можно попробовать написать прокси-cl.exe, который будет транслировать __dsl::, а потом вызывать настоящий cl.exe. Так вроде бы STLFilt работает.
0
Просто если уж подобную штуку использовать, то можно сразу на разные подпути повесить разные вспомогательные dsl, типа описания файлового формата или еще чего. Но для использования он должен как-то автоматом настраиваться у всех в компании.
Покопаю в сторону прокси-cl.exe, но вообще думал, может есть в студии подключаемые препроцессоры.
Покопаю в сторону прокси-cl.exe, но вообще думал, может есть в студии подключаемые препроцессоры.
0
в настройках проекта есть pre-build event, способный вызывать стороннюю программу. может поможет.
0
тем временем рождается новая эволюция С с типом auto вложенными функциями, foreach и другими вкусностями
trac.assembla.com/SuperCalc/browser
trac.assembla.com/SuperCalc/export/662/LanguageEN.html
trac.assembla.com/SuperCalc/browser
trac.assembla.com/SuperCalc/export/662/LanguageEN.html
0
Для того чтобы интегрировать в вижуал, я вижу два пути:
1) настраивать каждый раз вручную для проекта Pre-Build Events (собственно препроцессинг) и Post-Build Events (зачистка сгенерированных файлов). Впрочем, есть способ немного упростить процесс настройки, но всё равно будет не очень удобно.
2) писать код с кусками метапрограммирования в файлах с другим расширением. Тогда можно попробовать заюзать такую штуку как Custom Build Rules.
А отображение ошибок сделать проще простого. В MSDN описан формат, в котором кастомные тулзы должны выдавать ошибки и предупреждения. Если его придерживаться, то ошибки будут отображаться в окне Errors, а двойной клик на ошибку перебросит на нужную строку. Я так doxygen прикручивал когда-то.
P.S. Сорри, что без скринов. У меня вижуал на русском :)
1) настраивать каждый раз вручную для проекта Pre-Build Events (собственно препроцессинг) и Post-Build Events (зачистка сгенерированных файлов). Впрочем, есть способ немного упростить процесс настройки, но всё равно будет не очень удобно.
2) писать код с кусками метапрограммирования в файлах с другим расширением. Тогда можно попробовать заюзать такую штуку как Custom Build Rules.
А отображение ошибок сделать проще простого. В MSDN описан формат, в котором кастомные тулзы должны выдавать ошибки и предупреждения. Если его придерживаться, то ошибки будут отображаться в окне Errors, а двойной клик на ошибку перебросит на нужную строку. Я так doxygen прикручивал когда-то.
P.S. Сорри, что без скринов. У меня вижуал на русском :)
0
Я кликнул по заголовку только для того чтобы узнать о чем этот заголовок.
-1
Greenspun's Tenth Rule:
Аny sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp.
""«Любая достаточно сложная Ц или Фортран программа содержит по-быстренькому написанную нестандартную глючную медленную реализацию половины языка Lisp.»""
Аny sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp.
""«Любая достаточно сложная Ц или Фортран программа содержит по-быстренькому написанную нестандартную глючную медленную реализацию половины языка Lisp.»""
+1
Sign up to leave a comment.
DSL для boost::MPL, превращаем f(x) в f<x>::type