2009-09-19 52 views
1

有些断言代价高昂,有些断言在生产代码中更好。 至少不清楚应该始终启用断言。断言检查的便利策略

在我的应用程序中,我希望能够打开/关闭每个文件或每个类的部分断言。

如何在C++中执行此操作?

+0

在编译时或运行时打开/关闭? – 2009-09-19 14:05:28

+0

好点。在编译时。 – 2009-09-19 14:16:32

回答

2

用于停用断言模块范围内我会使用:

#if defined(assert) 
# undef assert 
# define assert(x) ((void)0) 
#endif 

...当然,如果你是好与使用自定义宏这样可以简化。

#if defined(_NO_ASSERTS) 
# define myAssert(x) ((void)0) 
#else 
# define myAssert(x) assert(x) 
#endif 

对于类范围内的失活我会使用一个静态常量类成员或类范围的枚举结合自定义宏:

#define myAssert(x) do { if(_CLASS_ASSERT) { assert(x); } } while(0) 

class AssertOff 
{ 
    enum { _CLASS_ASSERT = 0 } 
} 

随着枚举和静态常量的bool所有现代编译应该优化掉if(_CLASS_ASSERT) {}

+0

与枚举的好主意。谢谢。 – 2009-09-19 17:22:11

0

要为C++文件中禁用断言,您可以执行下列操作之一:

  • 定义附近的源文件的顶部NDEBUG不变。
  • -DNDEBUG添加到源文件的编译选项。

大多数IDE和/或构建基础结构允许您指定每个文件的构建选项,因此这是一个简单的解决方案。

当多个类混合到同一个源文件中,或者在头文件中有许多内联函数时,关闭每个类的断言更加困难。你当然可以在相关的地方#define NDEBUG#undef NDEBUG

由于一些IDE希望能够为非调试版本设置NDEBUG,您可以通过选择自己的宏名称(例如DISABLE_ASSERT)使其更具可扩展性。然后在通用头文件(未预编译)中包含类似以下代码:

#ifdef DISABLE_ASSERT 
#define NDEBUG 
#endif 
+1

'#define NDEBUG'除了禁用断言之外还可能有其他不良的副作用。 – 2009-09-19 16:20:42

+0

有什么副作用? – 2009-09-19 17:20:58

+0

禁用其他调试宏/代码,不仅声明。 – 2009-09-19 17:24:44

1

要断言的代码考虑良好的编码风格。

至于运行时间打开/关闭您可以用布尔变量来做到这一点。例如,在您的代码中,您可以执行以下操作:

定义一个变量,用于指示断言在全局命名空间中是打开还是关闭(例如,在同一个文件中的main()函数外) 。

bool turnOnAssertions; 

定义为下面写在其他文件中要开启/关闭你的断言一个变量:

extern bool turnOnAssertions; 

因此,通过与UI操纵turnOnAssertions变量和写作

if(turnOnAssertions) 
assert(…); 

你可以打开/关闭你的一些断言!

至于编译时,你应该做到以下几点:

为您编译器,你应该给像-DASSERTIONSON标志(-Dflag_name [标记名称,你可以设置你想要的任何东西])

#ifdef ASSERTIONSON 
bool turnOnAssertions = true; 
#else 
bool turnOnAssertions = false; 
#endif 

并只使用该变量。

祝你好运!