http://dlang.org/expression.html#AssertExpression
关于assert(0)：“编译的优化和代码生成阶段可能会假设它是无法访问的代码。”
相同的文档声称assert(0)是“特例”，但有几个原因。
D 编译器可以基于assert合同和其他地方的通用离子进行优化吗？
（好像我需要另一个理由来享受in{}andout{}结构，但知道写它们可以让事情变得更糟，这肯定会让我感到更加头晕目眩）
问问题
141 次
2 回答
4
理论上，是的，在实践中，我认为不会，特别是因为断言甚至在到达 dmd -release 上的优化器之前就被杀死了。我不确定 gdc 和 ldc，但我认为他们共享这部分代码。
顺便说一句，规范的特殊情况参考是 assert(0) 仍然存在，以某种形式，带有 -release 编译标志。它在那里被翻译成非法指令（asm {hlt;} - x86 上的非内核程序不允许使用它，因此它会在命中它时出现段错误），而所有其他断言完全被排除在代码之外-释放模式。
于 2013-08-12T22:21:48.123 回答
1
GDC 确实基于断言进行了优化。if 条件可以生成更好的代码，甚至会导致不必要的代码消失。然而，不幸的是，目前它的实现方式是整个断言可以在发布构建模式下消失，因此编译器永远不会看到有益的 if 条件信息，实际上在发布时生成的代码比在调试模式下更糟糕！讽刺。我不得不承认，我只在体内断言中的 if 条件下查看了这种效果，我还没有检查进出块有什么影响。可以基于命令行开关 iirc 关闭 in-out-etc 合约块，因此它们甚至没有被编译，我认为这可能意味着编译器甚至不看它们。所以这是可能影响代码生成的另一件事，我没有看过。但是这里有一个我非常希望看到的功能，即断言条件中的 if 条件真值（检查断言条件的表达式中是否没有副作用代码）始终可以注入编译器作为一个假设，就好像即使在发布模式下也有一个 if 语句。这将涉及假装您刚刚看到一个 if ( xxx ) 但在发布模式下抑制了测试的实际代码生成，
于 2017-03-01T07:52:00.007 回答