0

谷歌 C++ 风格指南 ( http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Preprocessor_Macros ) 说：

“而不是使用宏来有条件地编译代码......好吧，根本不要这样做”

为什么拥有这样的功能如此糟糕

void foo()
{
    // some code

#ifdef SOME_FUNCTIONALITY
    // code
#endif

    // more code
}

?

4

2 回答 2

4

正如他们在您链接到的文档中所说：

宏意味着您看到的代码与编译器看到的代码不同。这可能会引入意外行为，尤其是因为宏具有全局范围。

如果您只有一个条件编译，这还不错，但是如果您开始使用嵌套的条件编译，可能会变得很快变得复杂，例如：

#if PS3
  ...
#if COOL_FEATURE
  ...
#endif
  ...
#elif XBOX
  ...
#if COOL_FEATURE
  ...
#endif
  ...
#elif PC
  ...
#if COOL_FEATURE
  ...
#endif
  ...
#end
于 2013-10-05T01:28:34.507 回答
1

我相信一些反对它的论点：

  • #ifdef跨越 C++ 表达式/语句/函数/类语法。也就是说，喜欢goto它太灵活了，您无法相信自己会使用它。

  • 假设// code编译时的代码SOME_FUNCTIONALITY没有定义。然后只需使用ifastatic const bool并信任您的编译器即可消除死代码。

  • 假设代码在未定义时// code 无法编译。SOME_FUNCTIONALITY然后，您正在创建一个混合了有效代码和无效代码的狗早餐，以及相关代码和不相关代码，这可能可以通过更彻底地分离这两种情况来改进。

  • 预处理器是一个可怕的错误：Java 比 C 或 C++ 好得多，但如果我们想在金属附近乱搞，我们就会被它们困住。试着假装这个#角色不存在。

  • 显式条件是一个可怕的错误：多态性宝贝！

  • 谷歌的风格指南特别提到了测试：如果你使用#ifdef，那么你需要两个单独的可执行文件来测试你的代码的两个分支。这很麻烦，您应该更喜欢单个可执行文件，可以针对所有支持的配置进行测试。当然，同样的反对意见在逻辑上也适用于 a static const bool。一般来说，当您避免静态依赖时，测试会更容易。更喜欢注入它们，即使“依赖”只是一个布尔值。

我个人并不完全赞同任何论点——我个人认为，在特定情况下，杂乱的代码有时仍然是特定工作的最佳选择。但是 Google C++ 风格指南并不是要告诉您使用最佳判断。它的业务是设置统一的编码风格，并消除一些作者不喜欢或不信任的语言特性。

于 2013-10-05T01:37:20.310 回答