我从来没有断言的想法——你为什么要使用它们？
我的意思是，假设我是一名方程式赛车手，所有的断言都是诸如安全带、 Helm 等之类的东西。
测试(调试中)一切正常，但现在我们想做赛车(发布)! 我们是否应该放弃所有安全性，因为测试时没有问题？
我永远不会删除它们。我认为大多数声称删除与断言类似的东西的人从未分析过他们的代码，或者断言完全被取代了。 我从未见过任何真正的性能优势，尤其是关于 80/20 规则。
那么，我是否以某种方式错过了重点，或者有人可以告诉我，为什么我应该使用断言？ 顺便说一句，我正在使用单元测试。
最佳答案
首先，性能差异可能很大。在一个项目中，我们的断言确实导致了 3 倍的减速。但他们帮助我们发现了一些非常讨厌的错误。
这正是重点。
断言可以帮助您发现错误。而且因为它们在发布版本中被删除，我们可以在不担心性能的情况下放入大量它们。如果您不在现场对任何失败的断言采取实际行动，它们就会变得毫无值(value)，所以我们不妨删除它们。
即使捕获错误并抛出异常也不是真正的解决方案。程序逻辑有缺陷，即使我们处理了异常，程序还是坏了。
断言基本上归结为“为什么要费心去捕捉你无法处理的错误？”
在开发过程中必须发现一些错误。如果他们滑过测试并进入客户使用的发布版本，则程序只是损坏了，再多的运行时错误检查也无法修复它。
I never got the idea of asserts -- why should you ever use them?
I mean, let's say I were a formula driver and all the asserts were things like security belt, helmet, etc.
是的，这是不使用断言的一个很好的例子。这些是在运行时实际上可能出错的事情，需要检查。您的一级方程式车手可能会忘记一些安全预防措施，如果他忘记了，我们希望在任何人受伤之前停止这一切。
但是检查引擎是否已安装呢？ 在比赛中我们需要检查吗？
当然不是。如果我们在没有引擎的情况下参加比赛，我们就完蛋了，即使我们发现了错误，也为时已晚。
相反，这是一个必须在开发过程中捕获或根本不捕获的错误。如果设计人员忘记在他们的汽车中安装发动机，他们需要在开发过程中检测到这个错误。这是一个断言。开发的时候跟开发者有关系，但是后面的错误一定是不存在的，如果存在，我们也无能为力。
这基本上是不同的。通过处理可以处理的错误来帮助用户。
一个断言可以帮助您，通过提醒您从一开始就绝对不能发生的错误，这些错误必须在产品可以发货之前修复。不依赖于用户输入的错误，而是依赖于你的代码做它应该做的事情。
四的平方根必须从不计算为三。错误是根本不可能的。如果确实发生了，那么您的程序逻辑就被破坏了。我们围绕它进行多少错误处理并不重要，它是必须在开发过程中捕获的东西，或者根本不捕获。如果我们使用异常处理来检查这个错误并处理它，异常会做什么？告诉用户“程序从根本上坏了。永远不要使用它”？
开发者的一封电子邮件可以实现这一点。为什么要费心将其构建到程序代码中？这是一个根本不能发生的问题的例子。如果是这样，我们必须返回并修复程序。无法进行其他形式的错误处理。
但某些错误，例如无法打开文件进行阅读，是可能的。即使它发生可能是一件坏事，但我们必须接受它可能发生。所以如果是，我们需要处理它。
断言用于捕捉不可能发生的错误。
关于c++ - 为什么要使用断言？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1081409/