Regex的内部复杂程度太夸张了

抽空看了一下Regex的内部，不由得吓了一大跳，建议大家也“浏览”一下。我一开始还以为这个东西是用Native的代码来完成的，比如调用了mscorlib里面的某个NativeAPI，或者带上InternalCall的标志，因为它的速度性能确实不错。可是我大错特错了，整个的Regex竟然是用IL写的！内部的复杂程度不是一般的复杂啊，光看RegularExpression这个命名空间里面有多少的类就知道了——31个，这31个类几乎全部都是围绕着Regex这个类团团转的。有一些我们都知道，比如Group、Capture之类的。还有一些一眼看上去就知道大概是什么，比如RegexCompiler、RegexInterpreter。但是还有一些我就完全摸不着头脑了，比如RegexFCD，FCD是什么？可怕的是，这些不知道什么作用的东西占了大多数，我很希望搞懂他们的作用。

初步囫囵吞枣了一下，感觉RegexInterpreter的实现方式似乎不是NFA转换成近似DFA的方式，而是确确实实是一种执行。当然，有解释模拟的方式，也有编译运行的方式。看起来有点类似LL的这种方式，而不是LR，因为我没有看到状态表这样的东西。也许现在还没有仔细看没有看到，但是我觉得属于LR这样的归纳方式似乎是不可能的，因为.NET的正则表达式全部都是终结符，没有非终结符，那么怎么可能归纳呢？也许准确地说也不能够说是LL，因为同样没办法推导，不过至少应该是以“推导”的方式进行匹配的。

除了类的数量很多之外，还有很多地方都体现了他的复杂，例如一个叫做runanchor的变量，实在搞不懂他的意思，没有文档恐怕要直观的“看懂”是不可能的了，要找一个时间分析一下产生runanchor的值的代码才能够搞清楚它的含义。除了代码的复杂之外，结构的复杂性也是有点夸张的，比如说在这里看到了Factory模式（好像是的，现在没有仔细看，不知道是Factory还是别的什么模式，只是看到了factory这个字眼，并且确定是某种模式……）

看了半天我都没有办法确定一些什么重要的东西，唯一能够确定的是，Regex的速度性能确实不是我随便写个Parser能够达到的。如果想要更快的话，我估计也就只有把正则表达式转换成DFA了，不过NFA到DFA不是总是能够成功的。

呼，说不定我会放弃搞懂这个近乎于BT的Regex类的执行过程，还是尽早把NfaGen2做好吧。