在这种情况下，内联函数的宏有什么更好的？ [复制]答案

【问题标题】：What is better in this case, macro of inline function? [duplicate]在这种情况下，内联函数的宏有什么更好的？ [复制]
【发布时间】：2012-09-18 10:07:06
【问题描述】：

可能重复：
Inline functions vs Preprocessor macros
what is concept of Inline function and how it is differ from macro?

inline unsigned int getminutes( unsigned int seconds )
{
    return( seconds / 60 );
}

#define GetMinutes(seconds) (seconds) / (60)

说实话，我会问哪个更快，但我在 S.O 上看到的太多了，所以问哪个更好会让我知道。（是的！我是一名知识猎手）

【问题讨论】：

请完全括住表达式宏（不仅仅是宏参数）。这种错误是您可能应该倾向于内联函数的原因之一......
你为什么不学习基准测试呢？
@netcoder：嗯，他确实问过哪个更好，并说他会问哪个更快，但没有。
和stackoverflow.com/questions/6402613、stackoverflow.com/questions/1137575、stackoverflow.com/questions/4761504、stackoverflow.com/questions/8221275、stackoverflow.com/questions/3810221、stackoverflow.com/questions/8712967、stackoverflow.com/questions/4334041等等。
另一个要考虑的选项是const unsigned minutes = seconds / 60;。并不是说因素60 难以理解（“幻数”）或在程序的生命周期内可能会发生变化。

标签： c++

【解决方案1】：

如果您可以使用内联函数来实现相同的功能，请不要使用宏。假设您使用的是相当不错的解决方案，编译器将为您提供的两种解决方案生成完全相同相同的代码。

当然不能保证内联函数实际上会被内联，但在这些情况下，如果您的编译器不能内联该函数，那么它可能是一个非常糟糕的函数。

除非你真的需要，否则不要使用宏（标题保护，做重复的事情等）。宏在几个方面都是邪恶的，如果您在网上搜索信息，您可以阅读很多相关信息。

【讨论】：

【解决方案2】：

我猜如果您认为inline 不能由要使用的编译器保证，宏会更快。如果函数没有内联，那么你就有函数调用的开销。

宏将由预处理器展开，因此它始终是内联的。该宏也不是类型安全的，并且具有全局范围。

函数是首选。

【讨论】：

@MooingDuck 我编辑了我的答案
如果编译器太差以至于不能内联单行，我们怎么知道它没有实现除法作为对RTL_incredibly_slow_divide(seconds, 60)的调用？那么宏也不会被有效地内联。

【解决方案3】：

使用良好的优化编译器，性能将是相同的。不同之处在于内联函数或多或少是对编译器的建议。虽然编译器在大多数情况下应该遵守建议，但宏版本会强制编译器内联代码。

顺便说一句，您的宏应该写成((seconds) / 60) 以确保在所有情况下都使用预期的分组。

【讨论】：

【解决方案4】：

不幸的是，更快是唯一知道的方法是分析的情况之一。但是，我怀疑在典型的发布构建设置中结果是相同的。

哪个更好，但是，我会说内联函数。更容易调试。比宏更安全。

除非绝对必要，否则我会避免使用宏。我认为它们是编译时查找和替换。我认为查找和替换在最坏的情况下是非常危险的。实际上，我写了一个 post 或 two 来解释为什么我如此强烈地不喜欢 #define 宏...

我运行的另一个建议是：编译器比你更清楚。宏将强制内联，即使它实际上对性能不利。 inline 将建议它作为内联候选，但如果它不符合内联标准，则可能不会内联。

【讨论】：