java – 为什么一般来说嵌套阻止注释不允许?

前端之家收集整理的这篇文章主要介绍了java – 为什么一般来说嵌套阻止注释不允许?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在我使用的大多数语言中,你根本无法嵌套批注,因为“关闭评论sintaxis的第一次发生即使它只是一个“内在的”评论也会关闭评论.

例如,在HTML

<!-- outer comment
<p>hello</p><!-- inner comment <p>world</p> -->
<p>this should BE commented</p>
-->

在这种情况下,外部注释在第一个>而不是相应的最后一个,导致最后的< p>打印时,不应该.

对于使用/ * * /的块注释的语言,就像在java,PHP,css,javascript等中一样.

但是我的问题是为什么是这样的?为什么设计不允许?我提到“设计”,因为我真的怀疑是因为解析问题,我猜解析器完全有能力跟踪开放/ *,并关闭评论与他们相应的结束* / s但他们只是以某种方式决定它是不是一个好主意

我已经知道,这样做的一个解决方法是以某种方式改变内部关闭评论,以避免他们关闭,只有离开最后一个关闭.例如改变 – > s和* / s的内部> s和* / s.但是这显然不方便,当你只想丢弃代码块进行调试时,很难做到. (其他技术是将所有内容嵌套在if(false){}块中,但这不是这里的一点.

那么,我想知道的是为什么几种现代语言一般不允许嵌套评论?必须有一个很好的理由,除了“别人不做,我们也不会”对吧?

作为一个加号,有没有其他(不那么模糊)的语言,允许嵌套块评论

@H_502_19@解决方法
原因是历史性的,与编译器的架构有关.

为了提高效率,大多数编译器通常分两个阶段解析源代码lexical analysis和令牌流的实际parsing(由所述词法分析产生).词汇分析是识别个人令牌的部分,例如关键字,字符串,数字字面值和评论.

再次出于效率的原因,词汇分析传统上是通过finite-state machine实现的.这些有限状态机器恰好识别(= handle)regular languages,这完全符合上述令牌.但是,它不能识别嵌套的构造 – 这将需要一个更强大的机器(augmented by a stack).

因此,不允许嵌套的评论仅仅是一个交易方便的表现的决定,后来的语言一般都采用了惯例.

And as a plus,are there any other (not so obscure) languages that DO allow nested block comments?

有一些.评论已经提到了Haskell和Pascal.其他语言是D和F#.

原文链接:https://www.f2er.com/java/123568.html

猜你在找的Java相关文章