3

我正在编写一个包含许多断言的库。打开断言后，该库要慢得多，并且该库的全部意义在于它很快，因此断言仅在测试或诊断错误时才有意义。我正在使用 autoconf，要求用户了解这个问题并传递一个标志来配置以禁用断言似乎是标准做法。在这种情况下，只有专家用户会知道足够的知识来安装适当版本的库！这真的是我应该做的吗？如果是这样，除了“这是专家用户和其他程序员所期望的”之外，还有其他充分的理由吗？

编辑： 这是一个讨论示例，说明您不应该在发布模式下默认定义 NDEBUG，尽管没有其他原因，因为这样做令人惊讶。

4

2 回答 2

1

我想我现在已经想通了。定义 NDEBUG 的问题在于它可能导致未定义的行为。我的是一个包含一些非模板部分的模板库，所以我的代码被内联到其他人的二进制文件中。如果我在编译非内联代码时定义了 NDEBUG，然后在没有 NDEBUG 的情况下编译了客户端代码，那么标头中的代码将有两个不兼容的版本——一个带有断言，一个没有。这会导致未定义的行为，我曾经遇到过这个问题，因为我遇到过一次神秘的崩溃。所以我不认为图书馆应该定义 NDEBUG - 负责在给定计算机上编译所有内容的人或构建系统应该是决定 NDEBUG 的人。

但是，我不必定义 NDEBUG 只是为了让我的库在没有断言的情况下默认运行。我现在有一个宏 MYLIB_DEBUG 和 MYLIB_ASSERT。如果 MYLIB_DEBUG 未定义，则 MYLIB_ASSERT(X) 什么也不做。如果定义了 MYLIB_DEBUG，则 MYLIB_ASSERT(X) 定义为 assert(X)。这使得断言选择加入而不会弄乱 NDEBUG。

所以我目前对我的问题的回答是，默认情况下库可以关闭断言，如果你的接口有任何包含断言的内联函数，就不要通过定义 NDEBUG 来做到这一点。

于 2012-10-15T18:50:07.923 回答
-1

如果使用 assert 会使您的库变慢，请按照您的意愿进行操作并将其关闭。确保它被清楚地记录在案......并停止担心。

于 2012-07-29T00:31:57.370 回答