问题描述
我收集了很多在flex中匹配C样式多行注释的解决方案：
（1）忘记了引用
"/*" { BEGIN COMMENT; }
<COMMENT>"*/" { BEGIN INITIAL; }
<COMMENT>([^*]|\n)+|. { /* skip everything */ }
<COMMENT><<EOF>> {
fatal_error("unterminated comment!");
return 0;
}
<INITIAL>{
"/*" BEGIN(IN_COMMENT);
}
<IN_COMMENT>{
"*/" BEGIN(INITIAL);
[^*\n]+ // eat comment in chunks
"*" // eat the lone star
\n yylineno++;
}
（3）丢弃https://www.cs.virginia.edu/~cr4bd/flex-manual/Start-Conditions.html#Start-Conditions中的C条注释
%x comment
%%
int line_num = 1;
"/*" BEGIN(comment);
<comment>[^*\n]* /* eat anything that's not a '*' */
<comment>"*"+[^*/\n]* /* eat up '*'s not followed by '/'s */
<comment>\n ++line_num;
<comment>"*"+"/" BEGIN(INITIAL);
（4）difficulty getting c-style comments in flex/lex
"/*"((("*"[^/])?)|[^*])*"*/"
（5）https://stackoverflow.com/a/13368522/4438921
"/*"((\*+[^/*])|([^*]))*\**"*/"
（6）这实际上是一个用于匹配C样式多行注释的正则表达式字符串，我不确定是否可以为flex进行重写：https://stackoverflow.com/a/36328890/4438921
String pat = "/\\*[^*]*\\*+(?:[^/*][^*]*\\*+)*/";
实际上哪一个是最好的？
解决方法
给出的任何一种模式实际上都不适合C或C ++，因为它们没有考虑行拼接或三字组。 （您可能会认为三字母组合这些天不必要了，我也不会不同意，但是即使它们现在已被弃用，您仍可能需要处理使用它们的旧文件。）
（对于不是既不是C也不是C ++，但是具有类似多行注释的语言，这可能不是考虑因素。在那种情况下，这是在整体正则表达式和开始条件之间的折腾，但是我会选择避免因冗长的评论而减慢速度的开始条件。）
虽然您可以编写一个包含接头的整体正则表达式，但是如果使用基于开始条件的解决方案，则会发现编写（和读取）起来要容易得多。从flex手册中提取的两个，我认为（3）的性能略高，尽管在这两种情况下，我都倾向于让flex进行行号计数，而不是尝试明确地进行行数计数。即使%option yylineno一次将注释与一行匹配，也可能是一个好主意，因为注释可能会很长，并且针对不超过8k的令牌优化了flex。
要处理线接头，您可以将其修改为：
%option yylineno
%x COMMENT
splice (\\[[:blank:]]*\n)*
%%
[/]{splice}[*] BEGIN(COMMENT);
<COMMENT>{
[^*\\\n]+ /* eat anything that's not a '*' or line end */
"*"+[^*/\\\n]* /* eat up '*'s not followed by '/'s or line end */
[*]{splice}[/] BEGIN(INITIAL);
[*\\] /* stray '*' or backslash */
\n /* Reduce the amount of work needed for yylineno */
}
如果要处理三部曲，则需要扩展splice的定义，并为<COMMENT>向?添加更多规则。
行接头是行尾的反斜杠，表示下一行是连续行。反斜杠和换行符将从输入文本中删除，因此，续行的最后一个字符紧跟在续行的第一个字符之后。因此，以下是有效的注释：
/\
************** START HERE **************\
/
Gcc和clang（以及可能的其他编译器）允许在反斜杠字符后加上空格，因为否则，有效连续和反斜杠之间的区别是不可见的。
继续行几乎在任何其他处理之前进行处理，因此可以将它们放在字符串文字，注释或任何标记中。它们通常在#define预处理程序指令中使用，以符合预处理程序指令为单个输入行的要求。但是，有意混淆C代码的人可以更自由地使用它们。例如，它们可以用于将C ++样式的单行注释扩展到多条物理行：
// This is a comment...\
which extends over...\
three lines.
在行连续之前发生的唯一处理是三字组处理。您可以在Wikipedia（或其他地方）上搜索三部曲。我会限制自己注意反斜杠是具有等价三字符??/的字符之一。由于三字组合是在续行之前处理的，因此可以写出拼接的多行注释的第一个示例：
/??/
************** START HERE **************\
/
某些编译器默认不处理三字母组合；如果看到了三部曲，他们可能会发出警告。例如，如果要在gcc上尝试上述操作，则需要指定ISO C标准（例如-std=c11）或提供-trigraphs命令行标志。
我已经用这些代码测试了（1）-（5）解决方案，它们都按预期工作：
（1）正确的评论
/* this is a comment */ int a = 1; /* this is a comment */
/* this is a comment */
/* this is a comment */
/* this is a comment */
/* this is a comment */
/* this is a comment */
/* this is a comment */
int main(void) {
return /*
*/
0;
}
/* this is a comment */
他们都给我：
int a = 1;
int main(void) {
return
0;
}
这是预期的。
（2）带有/* xxx */ */的错误评论
/* this is a comment */ int a = 1; /* this is a wrong one */ */
他们都给我：
int a = 1; */
这是预期的。
（3）带有/* xxx <EOF>的错误评论：
/* this is comment */ int a = 1; /*** this is commment
他们都给我：
int a = 1; /*** this is comment
所以我认为所有（1）-（5）都能正常工作，也许它们的性能有所不同，但这是另外一回事了。
我个人更喜欢（4），原因如下：
- （1）-（3）写更多代码，（4）和（5）更简单。
- （4）模式比（5）简单。