请教一个正则匹配的问题

prolj

lex的代码之所以邪恶是因为是用yacc描述的。这两个著名的UNIX标准工具还是本着能不用就不用的原则。
状态机我见过最好的例子是lcc中的cpp（预处理）的词法分析实现

cjaizss

原帖由 prolj 于 2008-11-22 21:41 发表
lex的代码之所以邪恶是因为是用yacc描述的。这两个著名的UNIX标准工具还是本着能不用就不用的原则。
状态机我见过最好的例子是lcc中的cpp（预处理）的词法分析实现

lex和yacc这两个工具主要是为了让人降低劳动强度的.穿插在项目中的一些词法语法分析可以使用lex/yacc完成,比自己写要方便的多.词法语法分析这种纯算法的东西，一旦表示为C语言代码,先别论编写,就是调试也让人耗费很大精力,而编写成lex/yacc则会好的多.

flw2

今天大致看了一下，flex-2.5.3
基本和 cjaizss 说的类似
合并成一个自动机
a[^b]{30000} {}
(a|b)[^b]{30000} {}
直接就挂了， flex没有延迟生成状态，不像grep， 所以它只能限制状态的大小
最后转换表使用的是龙书上说的方法进行的压缩

我的规则就是太多了， 并在一起太大了，听说flex是并行的所以想看看它怎么做的
现在看来和grep做的除了表压缩和延迟生成state之外基本类似， 不过我要解决的问题本来也是没解的问题。 规则一大内存指数上升，没有办法

多谢几位

cjaizss

flw2的要求直接用lex可能做不到，因为lex的选中是排它的，也有是任何一个句子只会被其中一个正则表达式选中。而flw2的要求是被好几个正则表达式选中。其实模仿lex这样拼接状态机是可以的。我在想，是否可以把lex编译之后的结果再改一改，就可以符合flw2的要求呢。

nmap

呵呵，支持。

cjaizss

对于这个问题,我突然觉得直接用LEX也可以做出来

flw2

原帖由 cjaizss 于 2008-12-5 16:48 发表
对于这个问题,我突然觉得直接用LEX也可以做出来

像grep flex典型的比较好的实现也没有考虑到规则太多太复杂的情况
比如 flex 使用bubble， 理由是状态不会太多， grep 进行state生成时对postion集合操作使用一个大数组， 理由类似
至于flex优先匹配这些都很容易改动
不过flex不行， 因为flex实现的是match,不是search， flex本身不需要search

我的问题已经没有高度了， 只是工程问题了