Почему внедрение кода после компиляции лучше, чем внедрение кода перед компиляцией?

Итак, мы все знаем, что C # не имеет препроцессора макросов, подобного C (и есть хороший поток о том, почему здесь). Но теперь, когда AOP набирает обороты, похоже, что мы начинаем делать то, что мы делали с постпроцессорами, что мы раньше делали с препроцессорами (имейте в виду, что я только промочу ноги с помощью PostSharp, так что, возможно, я ошибаюсь).

Я большой поклонник атрибутов в C #, но если препроцессор был исключен по уважительным причинам (которые, как бывший пользователь MFC, я все еще сомневаюсь, но, тем не менее, принимаю), почему инъекция кода после компиляции лучше, чем предварительная версия. инъекция кода компиляции?


c# macros aop c-preprocessor postsharp
person dkackman    schedule 05.02.2010    source источник

Ответы (4)


arrow_upward
7
arrow_downward

Причины, по которым я выбрал посткомпиляцию при разработке PostSharp 5 лет назад:

  1. Языковой агностицизм.
  2. MSIL имеет более стабильные спецификации по сравнению с языками высокого уровня (которые обновляются каждые два года).
  3. В большинстве случаев MSIL - это уровень абстракции, который вам нужен при работе с аспектами. Вам не нужно знать все эквивалентные конструкции (подумайте, f 'using' и 'try-finally').
  4. До 2008 года никому не удавалось создать достойный компилятор C #. Трудности, с которыми столкнулся Моно, были достаточно впечатляющими, даже если они уже наверстали упущенное.
  5. Работа с двоичным кодом казалась намного быстрее, чем работа с исходным кодом.
  6. Работа с двоичной сборкой делает возможным ее выполнение - обрабатываемая сборка может трансформироваться сама. Это было неслыханно до того, как PostSharp Laos был выпущен впервые.

Тем не менее, реализации AOP для C / C ++ действительно являются предварительным компилятором (WeaveC), а реализации на Java - расширением компилятора (по той веской причине, что существует множество реализаций OSS компилятора Java).

-гаэль

person Gael Fraiteur    schedule 13.02.2010
comment
Я согласен, лично для вас это имеет смысл. Однако ни одна из компаний, в которых я работал, не смогла принять PostSharp по единственной причине - нестандартный дополнительный шаг в компиляции сборки, делающий практически невозможным интеграцию в более сложный процесс, чем просто простой. - person Ivan G.; 21.10.2015

arrow_upward
4
arrow_downward

Технически в Visual Studio есть опция предварительной компиляции для C #: Text Набор инструментов преобразования шаблонов (T4). Это позволяет вам делать довольно удивительные вещи на этапе предварительной компиляции и является основой довольно многих продуктов, таких как некоторые ORM и т. Д.

person Reed Copsey    schedule 05.02.2010
comment
Знаешь, я никогда в них не заглядывал. Я должен наконец дойти до этого. - person dkackman; 06.02.2010

arrow_upward
2
arrow_downward

Если бы вы выполняли предварительную компиляцию, вам пришлось бы интерпретировать исходные файлы со всех поддерживаемых вами языков, а затем сгенерировать код на этом языке, прежде чем он будет передан компилятору. С помощью постобработки вы можете просто использовать отражение, чтобы проверить сборки, был ли исходный язык C #, Visual Basic или что-то еще.

person Brandon Cuff    schedule 05.02.2010
comment
В том же духе я мог бы добавить, что код, скомпилированный на C #, компилируется в MSIL (если не указано иное), который все еще не является фактическим машинным кодом. Это код JIT. Таким образом, технически то, что вы называете постпроцессором, на самом деле является препроцессором, поскольку код компилируется во время выполнения. - person regex; 06.02.2010
comment
@regex: да, технически верно, однако в контексте моего вопроса MSIL является единицей компиляции так же, как PE с C ++ (ну, технически .NET dll по-прежнему является PE, но вы понимаете мою точку зрения). - person dkackman; 06.02.2010
comment
Значит, межъязыковая поддержка является основной причиной (см. @Nobugz ниже)? - person dkackman; 06.02.2010
comment
Я тоже согласен с nobugz. Разбирать и генерировать IL проще, чем C #. - person Brandon Cuff; 08.02.2010

arrow_upward
2
arrow_downward

Это проще простого. IL чертовски легче анализировать, чем исходный код C #. И это не зависит от языка.

person Hans Passant    schedule 05.02.2010
comment
Препроцессор подстановки текста не был исключен из .net, потому что это было сложно сделать; по крайней мере, согласно посту Гуннерсона. Однако языковой агностицизм я могу купить. - person dkackman; 06.02.2010
comment
Я не об этом говорил, препроцессор никогда не будет доступен. Что оставляет в качестве альтернативы только синтаксический анализ и переписывание исходного кода. Технически это возможно, но неприятно. - person Hans Passant; 06.02.2010