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?
The reasons why I chose post-compilation when designing PostSharp 5 years ago are:
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
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.
It is just simpler. IL is a heckofalot easier to parse than C# source code. And it is language agnostic.
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.