【问题标题】:Alternatives/Tools for #define hell C/C++#define hell C/C++ 的替代方案/工具
【发布时间】:2013-08-08 10:25:51
【问题描述】:

在我们的 C/C++ 项目中,我们使用了一个包含 #ifdef 和 #defines 的配置头(约 1000 行)

#if (defined(HW_1) || defined(SOME_TECHNOLOGY_SUPPORTED)) && defined(OTHER_TECHNOLOGY_SUPPORTED)
 #define SOME_FEATURE_AVAILABLE
#endif

在我们的构建配置中,我们预定义了一些传递给编译器的定义。这会在我们的配置头中产生不同的定义(如 SOME_FEATURE_AVEILABLE)。

由于我们的配置头很大,所以也有点乱。

这个#define地狱有什么替代品吗?

或者是否有任何工具可以帮助查看在什么情况下设置了哪些定义。

我们正在开发嵌入式固件,因此我们无法用运行时 if 替换条件编译。

【问题讨论】:

  • 你在哪个系统上编译。适用于哪个操作系统?寻找autoconfautotools ....
  • 如果你坚持使用 ANSI C89 和 ISO C++ 98,那么你就不需要它们。
  • 如果您定义静态 const 布尔值,编译器仍然可以优化掉条件。
  • 我会寻找cmake,尤其是configure_file 命令。
  • 您确定在某些情况下使用#define 而不是运行时条件时不会进行过早的优化吗?

标签: c++ c c-preprocessor buildconfiguration


【解决方案1】:

如果您的所有#define 都在一个配置文件中,您可以尝试进行仅预处理器编译,然后查找所有已定义的宏。例如,

$ gcc -DFEATURE1 -DFEATURE2 -E configuration.h | grep '#define'

【讨论】:

    【解决方案2】:

    您可能想了解并考虑 Alexandrescu 在其“现代 C++ 设计”一书中介绍的 C++ 基于策略的设计 (http://en.wikipedia.org/wiki/Policy-based_design)。

    【讨论】:

    • 我更喜欢“桥”模式而不是基于策略的设计:它无需模板或多重继承即可实现相同的目标。
    • 我猜桥接会产生一些运行时开销(?)。基于策略的设计(使用模板)没有。多重继承在这里不会导致问题,因为您不会将对象作为基类对象处理(不要以多态方式处理它们)。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2015-03-05
    • 1970-01-01
    • 1970-01-01
    • 2011-03-20
    • 1970-01-01
    • 1970-01-01
    • 2010-11-07
    相关资源
    最近更新 更多