标签 编译原理 下的文章

代码分为五个部分

  1. 读入文法并进行处理、扩展
  2. 求项目集规范族
  3. 构造 DFA
  4. 构造分析表
  5. 分析输入串

经过实验梳理了一遍 LR(0) 语法解析的过程，按照书上的顺序实现不是很复杂。
前面的实验都是用 C++ 写的，这次用 Java 写感觉各有千秋，各有方便和不方便的地方，比如 Java 无法 new 泛型定长数组HashMap<Character, String>[]，C++ 的话直接声明Map<char, string>[]就能用了。
Google 了一下貌似说就是 Java 不支持。详细解释：

作者：ylxfc 链接：https://www.zhihu.com/question/20928981/answer/39234969
来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

核心的问题在于Java范型和C#范型存在根本区别：Java的范型停留在编译这一层，到了运行时，这些范型的信息其实是被抹掉的；而C#的范型做到了MSIL这一层。Java的做法不必修改JVM，减少了潜在的大幅改动和随之而来的风险，也许同时也反映出Java Bytecode规范在设计之初的先天不足；C#则大刀阔斧，连CLR一起改以支持更彻底的范型，换句话说，在范型这一点上，感觉C#更C++一点。在Java中，Object[]数组可以是任何数组的父类，或者说，任何一个数组都可以向上转型成它在定义时指定元素类型的父类的数组，这个时候如果我们往里面放不同于原始数据类型，但是满足后来使用的父类类型的话，编译不会有问题，但是在运行时会检查加入数组的对象的类型，于是会抛ArrayStoreException：

String[] strArray = new String[20];
Object[] objArray =strArray;
objArray[0] = new Integer(1); // throws ArrayStoreException at runtime

因为Java的范型会在编译后将类型信息抹掉，这样如果Java允许我们使用类似
Map<Integer, String>[] mapArray = new Map<Integer, String>[20];
这样的语句的话，我们在随后的代码中可以把它转型为Object[]然后往里面放Map<Double, String>实例。这样做不但编译器不能发现类型错误，就连运行时的数组存储检查对它也无能为力，它能看到的是我们往里面放Map的对象，我们定义的<Integer, String>在这个时候已经被抹掉了，于是而对它而言，只要是Map，都是合法的。想想看，我们本来定义的是装Map<Integer, String>的数组，结果我们却可以往里面放任何Map，接下来如果有代码试图按原有的定义去取值，后果是什么不言自明。

主要解析器文件代码放在下面，完整代码在 https://github.com/heart4lor/LR0






- 阅读剩余部分 -