在 C++ 中将函数实现为宏的优点/缺点答案

【问题标题】：Advantages/disadvantages of implementing functions as macros in C++在 C++ 中将函数实现为宏的优点/缺点
【发布时间】：2013-04-30 17:40:09
【问题描述】：

将业务逻辑功能实现为宏是个好主意吗？

我继承了一些遗留的 C++ 代码，我发现很多业务逻辑功能都是用长而神秘的宏来实现的。

宏比函数有优势吗？使用宏的一般原理是什么？

哪种逻辑最适合宏？

这是一个简单的代码示例

#define INSERT_VALUES(IN,ID,EO)     {\
    double evaluationOutput = EO;\
    int controls = 0;\
    int input_controls = m_input_controls[IN];\
    if(m_value_list[IN].ShouldProcess())\
        {\
        evaluationOutput = m_evaluationOutput[IN];\
        controls = m_controls[IN];\
        }\
    VALUE_EXIST(evaluationOutput,controls,input_controls,IN,ID,Adj);\
    m_evaluationOutput[IN] = controls > 0 ? evaluationOutput : 0.0;\
    m_controls[IN] = controls;\
    m_input_controls[IN] = input_controls;\                                 
}

【问题讨论】：

很少需要宏——过度使用宏是一种“代码味道”。
从你继承的代码中，你的判断调用是什么？宏是否有用？
宏是隐藏一些杂乱/样板/重复代码的有用快捷方式。一个例子是通过短的（可能是参数化的）宏在类中生成一些常见的声明。然而，就业务逻辑而言，通过适当利用 C++ 武器库（模板、函数重载等）来实现简洁、可读和安全的代码，可以做得更好。所以，一般来说，答案是：否。
你确定是 C++ 代码，而不是 C？
是的，代码一直是 C++。在我的情况下，宏的使用是用于业务逻辑（如果 a> b 然后执行 c 或填充数组等），而不是用于条件编译。许多函数也被定义为#define MY_MACROS(A,B,C,D) GET##A() 然后它继续下去。

标签： c++ macros

【解决方案1】：

在 Effective C++ 中，Scott Meyers 在第 2 项中指出：

首选consts、enums和inlines而不是#defines

Meyers 特别提到了编写宏而不是函数的做法，他说：

#define 指令的另一个常见（错误）用法是使用它来实现看起来像函数但不会产生开销的宏函数调用。

这样的宏有很多缺点，想想就知道了痛苦。

幸运的是，您不必忍受这种废话。你可以得到宏的所有效率加上所有可预测的行为和通过使用内联模板来确保常规函数的类型安全功能。

[Real functions] 遵守范围和访问规则。例如，它使谈论私有的内联函数非常有意义班级。一般来说，没有办法用宏来做到这一点。

具体回答您的问题：

一些程序员编写宏而不是函数来避免函数调用的感知开销——这种可疑的做法通常没有什么可衡量的好处。
程序员过去常常使用预处理器来生成样板代码（也许现在仍然如此）。在现代 C++ 中，处理器的使用应仅限于 #include 和（可能）#ifdef/#ifndef 用于条件编译。

正如迈耶斯最后指出的那样：

现在还不是退役预处理器的时候，但你应该一定要给它长时间和频繁的假期。

【讨论】：

【解决方案2】：

没有。它们绝对不是函数的一般替代品。

宏具有代码本身所不具备的功能，特别是在编译之前创建和修改标记（代码）。

作为交换，它们失去了所有类型安全性，以及几乎所有可用于实际代码的语法糖。

当您必须做一些代码无法完成的事情，或者需要代码有条件地存在时（超级调试的东西，比如内存跟踪），宏就派上用场了。它们在提供更简洁或更易读的方式来做特定事情方面也有一定的价值（一个常见的例子是#define SUCCESS(x) (x >= 0)。但是，对于任何需要类型安全、异常捕获或由不常用的代码组成的东西）不必在编译时改变，它们几乎不合适。大多数看起来像是宏的代码可能更安全地用实际代码表示，这对业务逻辑很重要。

您可以获得的最接近的经验法则是在编译期间是否需要发生或更改某些事情。如果是这样，考虑一个宏，否则只需编写代码。请记住，模板算作代码，可以做很多您可能会想使用宏的事情，但可能更安全。

【讨论】：

#define ONE 1 是类型安全的。
它不提供任何类型的安全。宏在简单的文本搜索和替换（或多或少）上运行，完全超出了语言的安全规则。例如，模板是经过编译和类型检查的（错误消息可能同样神秘）。我在使用宏时遇到的大多数有趣问题要么与类型相关，要么来自不正确的间距/调用的巧妙的新符号。
“有些事情你可以做但不安全”与“没有什么可以做是安全的”不同。如果你想反对宏，至少要提出准确的论据。夸张会损害您的信誉。
宏既不提供也不强制执行任何类型安全。标准规则适用于宏处理后，但不适用于宏；这最终成为使用它们的常见问题。没有任何地方声明或暗示宏不能生成符合类型系统的代码，但它们本身完全在系统之外，没有固有的安全检查。
它们通常被认为不是类型安全的，无论该示例如何，都应被视为类型安全。

【解决方案3】：

长而神秘的东西都不好。如果存在性能问题的宏，您可以使用内联函数实现相同的结果。如果将它们用于简化表达式，则可以将它们重构为不那么神秘，并且更易于维护，前提是您有时间和金钱进行此类努力。

【讨论】：