Comments 14
Может, кто подскажет, как такое потеснее заинтегрировать в Visual Studio? Чтобы не создавать дополнительные файлы и номера строк для ошибок отображать.Можно попробовать написать прокси-cl.exe, который будет транслировать __dsl::, а потом вызывать настоящий cl.exe. Так вроде бы STLFilt работает.
Просто если уж подобную штуку использовать, то можно сразу на разные подпути повесить разные вспомогательные dsl, типа описания файлового формата или еще чего. Но для использования он должен как-то автоматом настраиваться у всех в компании.
Покопаю в сторону прокси-cl.exe, но вообще думал, может есть в студии подключаемые препроцессоры.
Покопаю в сторону прокси-cl.exe, но вообще думал, может есть в студии подключаемые препроцессоры.
в настройках проекта есть pre-build event, способный вызывать стороннюю программу. может поможет.
тем временем рождается новая эволюция С с типом 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
Для того чтобы интегрировать в вижуал, я вижу два пути:
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. Сорри, что без скринов. У меня вижуал на русском :)
В студии есть Property Menager, который позволяет сохранять настройки хранить в отдельном файле, можно даже «наследовать».
Да, я знаю. Как раз попытался об этом написать.
Я кликнул по заголовку только для того чтобы узнать о чем этот заголовок.
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.»""
Sign up to leave a comment.
DSL для boost::MPL, превращаем f(x) в f<x>::type