为什么C评论没有嵌套？ [英] Why don't C comments nest?
问题描述
大家好，
（道歉，如果这是在某个地方的FAQ，我找不到任何东西）。
差不多每次我用C或C ++做大量编码时，我都会希望C风格的评论能够嵌套。这样可以使调试变得更加方便（#if 0 /＃endif或编辑器宏）。
无论如何，这是一个明确的设计决策，或某种历史
神器？ （例如，当时解析太昂贵）。嵌套注释可能存在哪些其他类型的原因？
谢谢！
-Al-
大家好，
（如果这是在某个常见问题解答中的道歉，我找不到任何东西。
这是comp.lang.c中的问题20.20经常
问题（FAQ）列表位于< http：// c -faq.com/> ;.很难想象你怎么可能错过它，因为问题的
文本包含你的确切*复制品
主题行。
-
Eric Sosman
es ***** @ ieee-dot-org.inva lid
" Al" < tw*@haik.us在留言中写道
新闻：Xq ***************************** *@comcast.com。 ..
>
无论如何，这是一个明确的设计决定，还是某种历史性的
神器？ （例如，当时解析太昂贵）。嵌套注释可能存在哪些其他种类的原因？
一般来说，人类在与某种类型的系统交互时犯错误的概率与系统的状态有关暂停。
就使用
嵌套评论时出错的概率而言，请注意：
a）没有嵌套注释，解析器状态在* /后面是已知的。使用
嵌套注释，它不是。
b）嵌套注释为一个人意外地提供了更多的可能性
注释掉部分没有意识到的代码（导致严重的错误）。
当然，人们可以用#if 0做同样的论点，但在我看来
人眼看起来并不擅长选择/ *和* /并且
在一个复杂的字符流中匹配它们。
我不同意不支持嵌套注释的决定。这是意外的另一条路径。
-
David T. Ashley（dt *@e3ft.com ）
http://www.e3ft.com （咨询主页）
http://www.dtashley.com （个人主页） http://gpl.e3ft.com （GPL出版物和项目）
Eric Sosman写道：
< snip>
这是comp.lang.c中的问题20.20经常
问题（FAQ）列表位于< http：// c -faq.com/> ;.很难想象你怎么可能错过它，因为问题的
文本包含你的确切*复制品
主题行。
啊，好的捕获，抱歉。我正在寻找一个关于
评论的部分，并没有意识到它在杂项中。所以，我猜
它比C更早回到PL / I及以后。
谢谢，
-Al-
Hi all,
(Apologies if this is in a FAQ somewhere, I couldn''t find anything).
Almost every time I do any significant amount of coding in C or C++, I
end up wishing C-style comments would nest. It would make rapid
debugging much more convenient (vs. #if 0/#endif or editor macros).
Anyway, was this an explicit design decision, or some sort of historical
artifact? (e.g. too expensive to parse at the time). What other sorts of
reasons might exist against nesting comments?
Thanks!
-Al-
Al wrote:Hi all,
(Apologies if this is in a FAQ somewhere, I couldn''t find anything).This is Question 20.20 in the comp.lang.c Frequently
Asked Questions (FAQ) list at <http://c-faq.com/>. It is
hard to imagine how you could have missed it, since the
text of the question contains an *exact* replica of your
Subject line.
--
Eric Sosman
es*****@ieee-dot-org.invalid
"Al" <tw*@haik.uswrote in message
news:Xq******************************@comcast.com. ..>
Anyway, was this an explicit design decision, or some sort of historical
artifact? (e.g. too expensive to parse at the time). What other sorts of
reasons might exist against nesting comments?Generally, the probability of a human making a mistake in interacting with a
certain type of system is correlated with how much state the system holds.
In terms of the probability that a person will make a mistake when using
nested comments, note that:
a)Without nested comments, the parser state is known after "*/". With
nested comments, it is not.
b)Nested comments provide more possibilites for a person to accidentally
comment out portions of code without realizing it (leading to severe bugs).
Of course, one could make the same argument with #if 0, but it seems to me
that the human eye just isn''t very good at picking out "/*" and "*/" and
matching them up in a complex stream of characters.
I don''t disagree with the decision to not support nested comments. It is
just one more path for accidents.
--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)
Eric Sosman wrote:
<snip>This is Question 20.20 in the comp.lang.c Frequently
Asked Questions (FAQ) list at <http://c-faq.com/>. It is
hard to imagine how you could have missed it, since the
text of the question contains an *exact* replica of your
Subject line.Ah, good catch, sorry about that. I was looking for a section about
Comments and didn''t realize it was in Miscellaneous instead. So, I guess
it goes back further than C to PL/I and beyond.
Thanks,
-Al-
这篇关于为什么C评论没有嵌套？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
