《Design by Contract for Embedded Software》翻译( 九 ) _生活百科

DbC 还鼓励测试被系统结构所容纳。在嵌入式系统领域，逻辑分析仪或在线仿真器可以直接访问 CPU 的所有状态信息的日子早已一去不复返。即使你能访问 CPU 的所有地址和数据信号（你通常不能，因为根本没有足够的引脚），多级流水线和高速缓冲存储器使你不可能弄清里面发生了什么。该解决方案要求将测试工具（断言）直接集成到系统的固件中。你不能再设计一个系统而不从一开始就考虑到测试的开销。假设所有的 CPU 周期、RAM 和所有的 ROM 都被严格地用于手头的工作，是无法完成工作的。

Assertions in Production Code产品代码中的断言
The standard practice is to use assertions during development and testing, but to disable them in the final product by defining the NDEBUG macro. In Listing 1, I have replaced this macro with NASSERT, because many development environments define NDEBUG automatically when you switch to the production version, and I wanted to decouple the decision of disabling assertions from the version of software that you build. That’s because I truly believe that leaving assertions enabled, especially in the ship-version of the product, is a good idea.

标准做法是在开发和测试期间使用断言，但在最终产品中通过定义 NDEBUG 宏来禁用它们。在清单 1 中，我用 NASSERT 代替了这个宏，因为许多开发环境在你切换到生产版本时自动定义了 NDEBUG，我想把禁用断言的决定与你构建的软件版本脱钩。这是因为我真的相信，让断言处于启用状态，特别是在产品的出货版本中，是一个好主意。

The often-quoted opinion in this matter comes from C.A.R. Hoare, who considered disabling assertions in the final product like using a lifebelt during practice, but then not bothering with it for the real thing. I find the comparison of assertions to fuses more compelling. Would you design a prototype board with carefully rated fuses, but then replace them all with 0 W resistors (chunky pieces of wire) for a production run?

在这个问题上经常被引用的意见来自C.A.R.Hoare，他认为在最终产品中禁用断言就像在练习中使用救生圈，但在真正的比赛中却不屑于使用它。我发现把断言比作保险丝更有说服力。你会用精心设计的保险丝来设计一个原型板，但在生产过程中把它们全部换成 0W 的电阻（大块的电线）吗？

The question of shipping with assertions really boils down to two issues. First is the overhead that assertions add to your code. Obviously, if the overhead is too big, you have no choice. (But then I must ask how have you built and tested your firmware?) However, assertions should be considered an integral part of the firmware and properly sized hardware should accommodate them. As the price of hardware rapidly drops and its capabilities skyrocket, it just makes sense to trade a small fraction of the raw CPU horsepower and memory resources for better system integrity. In addition, as I mentioned earlier, assertions often pay for themselves by eliminating reams of defensive code.

使用断言的问题实际上可以归结为两个问题。首先是断言给你的代码带来的开销。很明显，如果开销太大，你就没有选择。(但是，我必须问，你是如何建立和测试你的固件的？）然而，断言应该被认为是固件的一个组成部分，适当大小的硬件应该容纳它们。随着硬件价格的迅速下降和能力的急剧上升，用一小部分原始 CPU 马力和内存资源来换取更好的系统完整性是有意义的。此外，正如我前面提到的，断言往往通过消除大量的防御性代码而得到回报。

The other issue is the correct system response when an assertion fires in the field. As it turns out, a simple system reset is for most embedded devices the least inconvenient action from the user’s perspective—certainly less inconvenient than locking up a device and denying service indefinitely. That’s exactly what happened the other day, when my wife’s cellular phone froze and the only way of bringing it back to life was to pull out the battery. (I don’t know how she does it, but since then she managed to hang her phone again more than once, along with our VCR and even the TV.) The question that comes to my mind is whether the firmware in those products used assertions (or whether the assertions have been enabled)—apparently not, because otherwise the firmware would have reset automatically.