Why is post-compilation code injection a better id

问题:

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?

回答1:

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

回答2:

Technically, there is a pre-compilation option for C# built into Visual Studio: The Text Template Transformation Toolkit (T4). This allows you to do pretty amazing things in a pre-compilation step, and is the basis of quite a few products, such as some ORMs, etc.

回答3:

If you were to do pre-compilation you would have to interpret the source files from all the different languages you support then generate code in that language before it gets passed to the compiler. With post-processing you can simply use reflection to examine the assemblies whether the original language was C#, Visual Basic, or whatever.

回答4:

It is just simpler. IL is a heckofalot easier to parse than C# source code. And it is language agnostic.