有些人喜欢在 C 中使用 inline 关键字，并将大函数放在头文件中。你认为什么情况下这样使用是无效的？我有时候觉得这样使用甚至很让人恼火，因为这很不寻常。
我的原则是，inline 应该用于访问非常频繁的小函数，或者为了进行实际类型检查。不管怎样，我的品味指导我，但我不确定如何最好地解释为什么对于大函数来说，inline 不是那么有用。
在这个问题中，有人建议编译器可以更好地猜测正确的操作方式。这也是我的假设。当我尝试使用这个参数时，人们回复说它在使用不同对象的函数时行不通。嗯，我不知道（例如，使用 GCC）。
感谢您的回答！
inline有两个作用：
#1非常有用（例如，如果定义很短，可以将其放在头文件中），即使#2被禁用也是如此。
实际上，编译器通常会更好地自行计算何时进行内联（特别是如果可用的话，进行基于性能分析的优化）。
以上两点均源自ISO/ANSI标准（ISO/IEC 9899:1999(E)，通常称为“C99”）。
在§6.9“外部定义”，第5段中：
外部定义是同时也是函数（不是内联定义）或对象的定义的外部声明。如果具有外部链接的标识符在表达式中使用（除了作为sizeof运算符的操作数之一，其结果是整数常量），则整个程序中必须恰好有一个标识符的外部定义；否则，就不应该有超过一个。
虽然C++中的等效定义明确命名为单一定义规则（ODR），但它具有相同的目的。外部变量（即非“static”，因此仅局限于单个翻译单元 - 通常是单个源文件）只能定义一次，除非它是一个函数并且是内联的。
在§6.7.4“函数说明符”中，定义了内联关键字：
将函数设置为内联函数意味着对该函数的调用尽可能快。[118]这样的建议的有效程度是实现定义的。
脚注（非规范性），但提供了澄清：
通过使用替代通常的函数调用机制（例如“内联替换”），可以实现上述目标。内联替换不是文本替换，也不会创建新函数。因此，在函数体中使用宏扩展时，使用的定义是函数体出现时的定义，而不是函数被调用的地方；标识符也引用了发生在该函数体范围内的声明。同样，函数只有一个地址，不管外部定义之外有多少内联定义。总结：大多数C和C++用户期望的内联功能并非他们所得到的。它的表面主要目的是避免功能调用开销，但这是完全可选的。但为了允许单独编译，需要放宽单一定义。
（标准中的所有强调都是引用）
编辑2：一些注意事项：
int16 sinLUT[ TWO_PI ];
static inline int16_t cos_LUT( int16_t x ) {
return sin_LUT( x + PI_OVER_TWO )
}
static inline int16_t sin_LUT( int16_t x ) {
return sinLUT[(uint16_t)x];
}
当进行大量数学计算时，如果您想避免浪费时间计算sin/cos，则可以用LUT替换sin/cos。
如果您在不使用inline的情况下编译，则编译器不会优化循环，输出的.asm文件将显示以下内容：
;*----------------------------------------------------------------------------*
;* SOFTWARE PIPELINE INFORMATION
;* Disqualified loop: Loop contains a call
;*----------------------------------------------------------------------------*
内联声明的重要之处在于它不一定会执行任何操作。编译器可以自由决定是否内联未声明的函数，并链接已声明为内联的函数。
不应该在大型函数中使用内联的另一个原因是库。每次更改内联函数时，可能会丢失ABI兼容性，因为已经针对旧版本头文件编译的应用程序仍然内联了旧版本的函数。如果将内联函数用作类型安全的宏，那么很有可能在库的生命周期内永远不需要更改该函数。但对于大型函数来说，这很难保证。
当然，这个论点仅适用于函数是公共API的情况。
当您使用函数指针时，内联是无效的。
仅在以下情况下内联函数才是有效的：当您遇到性能问题时，使用真实数据运行分析器，并发现某些小函数的函数调用开销非常大。
除此之外，我无法想象为什么要使用它。
没错。在大型函数中使用内联会增加编译时间，并且对应用程序的性能带来很少的额外提升。 内联函数用于告诉编译器要包含一个函数而不需要调用，因此它们应该是重复多次的小代码。 换句话说：对于大型函数来说，与自身函数实现成本相比，进行函数调用的成本可以忽略不计。
内联函数可以用于小型和频繁使用的功能，例如 getter 或 setter 方法。对于大型函数，不建议使用内联，因为它会增加可执行文件的大小。此外，对于递归函数，即使您将其设置为内联，编译器也会忽略它。
我主要使用内联函数作为类型安全的宏。有关于GCC添加链接时优化支持的讨论已经进行了一段时间，特别是自LLVM出现以来。不过我不知道实际上已经有多少被实现了。
个人认为在没有经过代码分析证明某一例程会存在瓶颈，且通过内联可以部分缓解该瓶颈时，不应该进行内联。
这又是Knuth所警告的过早优化问题的一个案例。