每个人都知道Dijkstra 给编辑的信件:转到被认为有害的声明(也就是这里 .html脚本和这里的 .pdf)并且从那时起就有一个强大的推动,尽可能避开goto声明.虽然可以使用goto来生成不可维护的,庞大的代码,但它仍然保留在现代编程语言中.甚至Scheme中的高级连续控制结构也可以被描述为复杂的goto.
什么情况下可以使用goto？什么时候最好避免？
作为后续问题:C提供了一对函数setjmp和longjmp,它们不仅可以在当前堆栈帧内,而且可以在任何调用帧中进行转换.这些应该被视为像goto一样危险吗？更危险吗？
Dijkstra本人对这个头衔表示遗憾,他对此不负责任.在EWD1308(也是这里 .pdf)结束时,他写道:
最后是一个短篇小说的记录.1968年,ACM的通讯以" 被认为有害的goto声明 "的标题发表了我的一篇文章,遗憾的是,在后来的几年中,这一期刊最常被引用,但是,经常被作者看到的不多于标题,通过成为一个模板成为我的名声的基石:我们会看到几乎任何X的标题"X被认为有害"的各种文章,包括一个标题为"Dijkstra被认为有害"的文章.但是发生了什么？我提交了一份题为" 反对goto声明的案件 "的论文"为了加快出版速度,编辑已经变成了一封"给编辑的信",并在此过程中给了他一个新的自己的发明名称!编辑是Niklaus Wirth.
关于这个主题的经过深思熟虑的经典论文,与Dijkstra的相关,是结构化编程,由Donald E. Knuth撰写.阅读都有助于重新建立背景和对主题的非教条性理解.在本文中,Dijkstra对此案的观点得到了报道,甚至更为强烈:
Donald E. Knuth:我相信通过提出这样一种观点,我实际上并不同意Dijkstra的观点,因为他最近写了以下内容:"请不要陷入相信我非常悲惨的陷阱.去发言.我有其他人正在一个宗教出来的不舒服的感觉,就好像编程的概念问题可以通过一个单一的技巧来解决,通过编码规则的简单形式! "
goto在几个SO讨论中已经对这个声明进行了长时间的讨论(见这个和那个),我当然不想重振那些激烈的辩论.
相反,我想专注于gotos 的单个用例并讨论它的价值和可能的替代方案.
请考虑以下代码片段,这在(至少我自己的)FSM中很常见:
while (state = next_state()) {
switch (state) {
case foo:
/* handle foo, and finally: */
if (error) goto cleanup;
break;
case bar:
/* handle bar, and finally: */
if (error) goto cleanup;
break;
/* ...other cases... */
}
}
return ok;
cleanup:
/* do some cleanup, i.e. free() local heap requests, adjust global state, and then: */
return error;
在一个单独的函数中交换清理东西只是为了保存gotos似乎很尴尬.另一方面,我们已经被提出来谴责goto尽可能使用s.
我的问题:我的代码示例被认为是好风格吗？
如果没有,是否有可行的替代方案？
请坚持上述具体用法goto …
我在C程序中找到了以下代码:
while (1)
{
do_something();
if (was_an_error()) break;
do_something_else();
if (was_an_error()) break;
[...]
break;
}
[cleanup code]
这里while(1)用作"终于"的本地模拟.你也可以用gotos 写这个:
do_something()
if (was_an_error()) goto out;
do_something_else()
if (was_an_error()) goto out;
[...]
out:
[cleanup code]
我认为goto解决方案是一种常用的习惯用法.我在内核源代码中看到过几次这种习惯用法,在Diomidis Spinellis的"代码阅读"一书中也提到过.
我的问题是:什么解决方案更好？有没有具体的理由使用该while(1)解决方案？
问题943826没有回答我的问题.