5

So we all know that C# doesn't have a C-like macro pre-processor (and there's a good thread on why here). But now that AOP is gaining traction, it seems like we're starting to do stuff with post-processors that we used to do with pre-processors (bear in mind that I am only getting my feet wet with PostSharp so am perhaps off base).

I am a huge fan of attributes in C#, but if a pre-processor was left out for good reasons (which, as a former MFC user I still question but nevertheless accept) why is post-compilation code injection a better idea than pre-compilation code injection?

4

4 回答 4

7

The reasons why I chose post-compilation when designing PostSharp 5 years ago are:

  1. Language agnosticism.
  2. MSIL has stabler specifications compared to high-level languages (which have non-trivial updates every second year).
  3. Most of the time, MSIL is the level of abstraction you need when dealing with aspects. You don't need to know all the equivalent constructs (think f 'using' and 'try-finally').
  4. Before 2008, nobody has succeeded in producing a decent C# compiler. The difficulties met by Mono were impressive enough, even if they have caught up now.
  5. Dealing with binary seemed much faster than dealing with source code.
  6. Dealing with a binary assembly makes it possible to execute it -- the assembly being processed can transforme itself. It was unheard before PostSharp Laos was first released.

That said, implementations of AOP for C/C++ are indeed a pre-compiler (WeaveC) and implementations in Java are a compiler extension (for the good reason that there are many OSS implementations of the Java compiler).

-gael

于 2010-02-13T16:54:12.103 回答
4

从技术上讲，Visual Studio 中内置了 C# 的预编译选项：文本模板转换工具包 (T4)。这允许您在预编译步骤中做一些非常棒的事情，并且是很多产品的基础，例如一些 ORM 等。

于 2010-02-05T22:32:29.470 回答
2

如果您要进行预编译，则必须解释您支持的所有不同语言的源文件，然后在将其传递给编译器之前以该语言生成代码。通过后处理，您可以简单地使用反射来检查程序集，无论原始语言是 C#、Visual Basic 还是其他语言。

于 2010-02-05T22:08:35.340 回答
2

它只是更简单。IL 比 C# 源代码更容易解​​析。它与语言无关。

于 2010-02-05T22:22:51.160 回答