在C99中，没有“静态”或“外部”的“内联”曾经有用吗？

Question 1

当我尝试构建此代码时

inline void f() {}

int main()
{
    f();
}

使用命令行

gcc -std=c99 -o a a.c

我收到一个链接器错误（对的未定义引用f）。如果我使用static inline或extern inline而不是just inline，或者使用进行编译，则该错误消失-O（因此该函数实际上是内联的）。

这种行为似乎在C99标准的6.7.4（6）段中定义：

如果翻译单元中某个函数的所有文件范围声明都包含inline不带的函数说明符extern，则该翻译单元中的定义为内联定义。内联定义不为函数提供外部定义，也不禁止在另一个翻译单元中使用外部定义。内联定义提供了外部定义的替代方法，翻译器可以使用该替代方法在同一翻译单元中实现对该函数的任何调用。未指定对函数的调用是使用内联定义还是使用外部定义。

如果我正确理解了所有这些内容，则具有inline上面示例中定义的功能的编译单元仅在存在相同名称的外部函数的情况下一致地编译，并且我永远不知道自己的函数还是外部函数被调用。

这种行为不是完全愚蠢吗？在inline不使用C99的情况下static或extern在C99中定义功能是否有用？我想念什么吗？

答案摘要

当然，我错过了一些东西，而且行为也不愚蠢。:)

正如Nemo解释的那样，想法是放置函数的定义

inline void f() {}

在头文件中，只有一个声明

extern inline void f();

在相应的.c文件中。仅extern声明触发外部可见的二进制代码的生成。inline在.c文件中确实没有使用-仅在标头中有用。

正如乔纳森回答中所引用的C99委员会的基本原理所阐明的那样，inline所有内容都与编译器优化有关，该优化要求函数定义在调用现场可见。这只能通过将定义放在标头中来实现，当然，标头中的定义一定不能在每次编译器看到它时都发出代码。但是由于没有强制编译器实际内联函数，因此外部定义必须存在于某处。

Question 2

实际上，这个出色的答案还可以回答您的问题，我认为：

extern内联有什么作用？

这个想法是可以在头文件中使用“内联”，然后在.c文件中使用“外部内联”。“外部内联”就是您如何指示编译器哪个对象文件应包含（外部可见的）生成代码。

[更新，详细说明]

我认为.c文件中“内联”（没有“静态”或“外部”）没有任何用处。但是在头文件中这是有道理的，并且它需要某些.c文件中的相应“外部内联”声明才能实际生成独立代码。

Question 3

根据标准（ISO / IEC 9899：1999）本身：

附录J.2未定义行为

...

具有外部链接的inline功能是通过功能说明符声明的，但未在同一转换单元（6.7.4）中定义。

...

C99委员会写了基本原理，其中说：

6.7.4功能说明符

C99的一个新的特点：该inline关键字，改编自C ++，是一个函数说明符只能在函数声明被使用。对于需要在呼叫现场可见函数定义的程序优化而言，这很有用。（请注意，标准并未尝试指定这些优化的性质。）

如果函数具有内部链接，或者具有外部链接，并且调用与外部定义位于同一转换单元中，则可以确保可见性。在这些情况下， inline关键字在函数的声明或定义中的存在除了表明优先选择该函数的调用优先于未使用inline关键字声明的其他函数的调用之外，没有其他作用。

对于具有外部链接的函数的调用，可见性是一个问题，其中该调用与该函数的定义位于不同的转换单元中。在这种情况下，inline关键字允许包含调用的翻译单元也包含函数的本地或内联定义。

程序可以包含具有外部定义的翻译单元，具有内联定义的翻译单元以及具有声明但没有功能定义的翻译单元。后一个翻译单元中的调用将照常使用外部定义。

函数的内联定义被认为是与外部定义不同的定义。如果func在可见内联定义的地方发生了对具有外部链接的某些函数的调用，则其行为与对__func具有内部链接的另一个函数的调用相同。合格程序不得依赖于调用哪个函数。这是标准中的内联模型。

符合标准的程序不得依赖于使用内联定义的实现，也不得依赖于使用外部定义的实现。函数的地址始终是与外部定义相对应的地址，但是当使用该地址调用函数时，可以使用内联定义。因此，以下示例可能无法达到预期的效果。
inline const char *saddr(void)
{
    static const char name[] = "saddr";
    return name;
}
int compare_name(void)
{
    return saddr() == saddr(); // unspecified behavior
}
由于实现可能将内联定义用于对其中一个的调用，saddr而将外部定义用于对另一个的调用，因此不能保证等于操作的求值等于1（true）。这表明内联定义中定义的静态对象与外部定义中的相应对象不同。这激发了限制，甚至无法定义const这种类型的非对象。

内联以可以使用现有链接器技术实现的方式添加到标准中，并且C99内联的子集与C ++兼容。这是通过要求将包含内联函数定义的一个翻译单元指定为提供该函数的外部定义的单元来实现的。因为该规范仅由一个声明组成，该声明要么缺少inline关键字，要么包含inlineand extern，所以C ++转换程序也将接受它。

C99中的内联确实以两种方式扩展了C ++规范。首先，如果inline在一个翻译单元中声明了一个函数，则无需inline在其他所有翻译单元中声明该函数。例如，这允许将库函数内联到库函数中，但只能通过其他地方的外部定义来使用。为外部函数使用包装器函数的替代方法需要一个附加名称；例如：如果翻译人员实际上没有进行内联替换，那么这也可能会对性能产生不利影响。

其次，将内联函数的所有定义“完全相同”的要求替换为以下要求：程序的行为不应取决于是否使用可见的内联定义或外部定义来实现程序的行为。功能。这允许将内联定义专门用于特定翻译单元中。例如，库函数的外部定义可能包含一些参数验证，而对于从同一库中的其他函数进行的调用则不需要这些参数验证。这些扩展确实提供了一些优势。而关心兼容性的程序员可以简单地遵守更严格的C ++规则。

请注意，这是没有合适的实现来提供的标准头的标准库函数内置定义，因为这会打破一些旧的代码，包括它们的头后redeclares标准库函数。该inline关键字仅旨在为用户提供建议功能内联的可移植方式。由于标准标头不必是可移植的，因此实现具有以下其他选择：
#define abs(x) __builtin_abs(x)
或其他用于内联标准库函数的非便携式机制。

Question 4

~~>我收到一个链接器错误（对的未定义引用f）~~

~~在这里工作：Linux x86-64，GCC 4.1.2。可能是编译器中的错误；我在标准的引用段落中没有看到禁止给定程序的任何内容。注意使用if而不是iff。~~

内联定义提供了外部定义的替代方法，翻译器可使用该外部定义在同一翻译单元中实现对该函数的任何调用。

因此，如果您知道函数的行为f并希望在一个紧密的循环中调用它，则可以将其定义复制粘贴到模块中以防止函数调用。或，您可以提供一个对于当前模块而言等效的定义（但跳过输入验证或您可以想象的任何优化）。但是，编译器编写器可以选择优化程序大小。