每个人都知道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的观点,因为他最近写了以下内容:"请不要陷入相信我非常悲惨的陷阱.去发言.我有其他人正在一个宗教出来的不舒服的感觉,就好像编程的概念问题可以通过一个单一的技巧来解决,通过编码规则的简单形式! "
这个问题实际上是不久前在programming.reddit.com 上进行有趣讨论的结果.它基本归结为以下代码:
int foo(int bar)
{
int return_value = 0;
if (!do_something( bar )) {
goto error_1;
}
if (!init_stuff( bar )) {
goto error_2;
}
if (!prepare_stuff( bar )) {
goto error_3;
}
return_value = do_the_thing( bar );
error_3:
cleanup_3();
error_2:
cleanup_2();
error_1:
cleanup_1();
return return_value;
}
goto这里的使用似乎是最好的方法,导致所有可能性中最干净,最有效的代码,或者至少在我看来.在Code Complete中引用Steve McConnell :
goto在分配资源,对这些资源执行操作,然后释放资源的例程中很有用.使用goto,您可以清理代码的一部分.goto可以降低忘记在检测到错误的每个位置释放资源的可能性.
此方法的另一个支持来自本节中的" Linux设备驱动程序"一书.
你怎么看？这种情况goto在C中是否有效？您是否更喜欢其他方法,这些方法会产生更复杂和/或效率更低的代码,但是要避免goto？
请指出一个有效的Bose-Hibbard Sort实现的代码,最好是类似C语言的代码.
我正在尝试在C#中实现该算法,但我没有该算法的副本.我唯一的样本是Fortran实现,它是Hibbard原始Algol版本的"免费翻译"(来自'一个简单的排序算法'期刊的ACM第10卷(1963)p142-50 - 我也没有) .Fortran版本似乎是错误的(它只进行了1次比较,如果它们已经排序则最终退出)所以我主要关注的是获得一个可用的版本来学习.