在 C++ 中实现断言检查的最佳方法是什么？

Question

我的意思是，我需要做什么才能在代码中包含有用的断言？

MFC很简单，我只是使用ASSERT（一些东西）。

非MFC的方式是什么？

编辑：是否可以在assert.c中停止断言中断，而不是在我的文件中调用assert()？

编辑： 和之间有什么区别？ ？

接受的答案：这篇文章中有很多很好的答案，我希望我可以接受多个答案（或者有人会将它们全部合并起来）。 因此，答案被授予 Ferruccio（第一个答案）。

Answer 1

#include <cassert>

assert(something);

对于编译时检查，Boost 的静态断言非常有用：

#include <boost/static_assert.hpp>

BOOST_STATIC_ASSERT(sizeof(int) == 4);  // compile fails if ints aren't 32-bit

Answer 2

这取决于您是否正在寻找在 Visual C++ 之外工作的东西。 它还取决于您正在寻找什么类型的断言。

有几种类型的断言：

1. 预处理器
   这些断言是使用预处理器指令#error
   完成的
   预处理器断言仅在预处理阶段进行评估，因此对于模板等内容没有用处。

2. 执行时间
   这些断言是使用
   中定义的 assert() 函数完成的
   执行时断言仅在运行时评估。 正如 BoltBait 指出的那样，如果定义了 NDEBUG 宏，则不会编译。

3. 静态
   正如您所说，这些断言是通过使用 ASSERT() 宏来完成的，但前提是您使用的是 MFC。 我不知道作为 C/C++ 标准一部分的另一种执行静态断言的方法，但是 Boost 库提供了另一种解决方案：static_assert。
   Boost 库中的 static_assert 函数将被添加到 C++0x 标准。

作为附加警告，Ferruccio 建议的 assert() 函数与 MFC ASSERT() 宏的行为不同。 前者是执行时断言，而后者是静态断言。

我希望这有帮助！

Answer 3

断言（通常）仅

用于调试 “断言”的问题在于它通常位于调试二进制文件中，并且一些开发人员使用它们就好像代码仍在生产中一样。

这本身并不是邪恶的，因为代码应该经过集中测试，因此，产生断言的错误肯定会被发现并删除。

但有时（大多数时候？），测试并不像想要的那么密集。 我不会谈论我们必须直到最后一刻才编写代码的旧工作（不要问...有时，经理只是...咳咳...）...添加到代码中的断言有什么意义，该代码将在下一分钟编译并作为发布二进制文件传递给客户端？

在（某些）现实生活应用程序中进行断言

在我们的团队中，我们需要一些东西来检测错误，同时需要一些东西来处理错误。 我们可能在发布版本中需要它。

断言只会在调试构建时检测和处理错误。

因此我们添加了一个 XXX_ASSERT 宏以及一个 XXX_RAISE_ERROR 宏。

XXX_ASSERT 宏将执行与 ASSERT 宏相同的操作，但它将在调试和发布中构建。 它的行为（写入日志、打开消息框、不执行任何操作等）可以由 .INI 文件控制，然后，它将中止/退出应用程序。

这被用作：

bool doSomething(MyObject * p)
{
   // If p is NULL, then the app will abort/exit
   XXX_ASSERT((p != NULL), "Hey ! p is NULL !") ;
   
   // etc.
}

XXX_RAISE_ERROR 宏只会“记录”错误，但不会尝试处理它。 这意味着它可以将消息记录在文件中和/或打开带有消息的 MessageBox 和一个用于继续的按钮，以及另一个用于启动调试会话的按钮（根据 .INI 文件配置）。 这被用作：

bool doSomething(MyObject * p)
{
   if(p == NULL)
   {
      // First, XXX_RAISE_ERROR will alert the user as configured in the INI file
      // perhaps even offering to open a debug session
      XXX_RAISE_ERROR("Hey ! p is NULL !") ;
      // here, you can handle the error as you wish
      // Than means allocating p, or throwing an exception, or
      // returning false, etc.
      // Whereas the XXX_ASSERT could simply crash.
   }
   
   // etc.
}

在我们的库中引入它们一年后，仅使用 XXX_RAISE_ERROR。 当然，它不能用在应用程序的时间关键部分（我们有一个 XXX_RAISE_ERROR_DBG），但在其他地方，它都很好。 事实上，人们可以使用任何首选的错误处理，并且可以在开发人员计算机、测试人员甚至用户上随意激活它，这一事实非常有用。

Answer 4

要回答第二次“编辑”中的问题：

< 断言.h> 是 C 标头

< 卡塞特> 是 C++ 标准库头文件...它通常包括 < 断言.h>

Answer 5

基本断言使用

#include <cassert>

/* Some code later */
assert( true );

最佳实践说明

断言用于识别应该为真的运行时状态。 因此，它们是在发布模式下编译出来的。

如果您希望断言始终命中，则可以将 false 传递给它。 例如：

switch ( someVal ):
{
case 0:
case 1:
  break;
default:
  assert( false ); /* should never happen */
}

还可以通过断言传递消息：

assert( !"This assert will always hit." );

成熟的代码库经常扩展断言功能。 一些常见的扩展包括：

• 在每个模块的基础上切换断言以本地化测试。
• 创建一个在大多数调试版本中编译出来的附加断言宏。 这对于调用非常频繁（每秒数百万次）并且不太可能出错的代码来说是理想的。
• 允许用户禁用当前命中的断言、编译单元中的所有断言或代码库中的所有断言。 这会阻止良性断言被触发，从而创建不可用的构建。

Answer 6

要中断调用断言的文件，您可以使用引发异常或调用 __debugbreak 的自定义宏：

#define MYASSERT(EXPR, MSG) if (!(EXPR)) throw MSG;

或者：

#define MYASSERT(EXPR) if (!(EXPR)) __debugbreak();

Answer 7

Microsoft 特定的 CRT 断言

#include <crtdbg.h>
#include <sstream>
...
// displays nondescript message box when x <= 42
_ASSERT(x > 42);
// displays message box with "x > 42" message when x <= 42
_ASSERTE(x > 42);
// displays message box with computed message "x is ...!" when x <= 42
_ASSERT_EXPR(
   x > 42, (std::stringstream() << L"x is " << x << L"!").str().c_str());

Answer 8

有一个更高级的开源库，称为 ModAssert，它的断言适用于 Visual C++ 和 gcc。 可能也在其他编译器上，不确定。 学习它需要一些时间，但如果您想要不依赖于 MFC 的良好断言，请查看这些。 它位于 http://sourceforge.net/projects/modassert/

Answer 9

使用智能感知在 Visual Studio 中打开它（右键单击）

// cassert standard header
#include <yvals.h>
#include <assert.h>

yvals.h 是 Windows 的东西。 因此，就assert()本身而言，包含它的两种方法是相同的。 使用 是一个很好的做法，因为它通常不是那么简单（命名空间包装和其他魔法）

这对我来说在调用者站点会中断......

这是一个 文章 解释为什么您不想自己编写此宏。

Answer 10

这是我在 C++ 中对断言工具的最新迭代： http://pempek.net/articles/2013/11/17/cross-platform-cpp-assertion-library/

这是一个嵌入式 2 个文件库，您可以轻松添加到您的项目中。

Answer 11

回答提问者的第三个问题：
我们使用“cassert”而不是“assert.h”的第一个原因是，就 C++ 而言，考虑到 C++ 编译器可能不会将函数描述存储在代码文件中，而是存储在 dll 或在编译器本身。
第二个问题是，无论是现在还是将来，为了区分 C 和 C++ 之间的差异，可能会对函数进行微小的更改。 因为assert.h 是一个C 库，所以在C++ 中首选使用“cassert”。