c - 我应该在 C99 中故意跨翻译单元内联函数吗

Question

在我的问题中，我最初问了这四个问题

在 C99 编译器中，当涉及跨翻译单元内联时，inline 实现的行为是否已定义？

如果是这样，应该避免吗？

还有其他一些普遍接受的方法吗？

如果我的 inline 函数没有在任何地方内联，我至少会得到某种链接器错误吗？

在我的 OP 之后，我发现第一个问题已经在以下线程中进行了详细讨论:

How to declare an inline function in C99 multi-file project?

Is inline without static or extern ever useful in C99?

关于这个话题有更多的线索，但这两个似乎一针见血。

因此，基于这两个讨论，我们可以看到问题 1 的答案是肯定的。编译器肯定有一些自由 W.R.T.他们如何处理 inline 说明符。

我们还看到，要使其工作，必须在头文件中定义 inline 函数。

除此之外，还有以下选项:

头文件中的函数定义可能有一个 static 说明符。

如果头文件定义没有 static 说明符，它可以通过 extern 在一些通用头文件中声明，所有调用该函数的 C 文件也将 #include 。

如果不使用方法 2 和方法 3，方法 4 将在每个希望调用它的 C 文件中通过 inline 声明这个 extern 函数。

所以，既然所有这些解释都已不复存在，我想把这个问题重新集中在我原来的项目 #2 和 #3 上——我是否应该这样做，如果是这样，最可接受的方式是什么？

我应该这样做 - 还是应该尽可能避免？

考虑我的应用程序——我在一个驱动程序中有一个单行函数，它被频繁调用(大约每秒几百次)，但只能从 3 或 4 个其他地方调用。所以使用 inline 不会导致代码膨胀——实际上结果可以忽略不计。 Gregory Pakosz 概述了何时使用 inline 函数以及何时不使用 this answer 。因此，如果这是在一个翻译单元中使用的一个函数，那么答案将非常明确。但这不是我要问的。

在这种情况下，我不需要内联这个函数。但我应该吗？我可能永远不会注意到任何性能差异，因为我只内联了这个函数。但我想弄清楚是否应该在所有类似情况下将其作为我的一般做法。如果我内联经常被更积极调用的短函数，我可能会看到性能改进。 (我的运行时环境是一个低功耗的 16 位 RISC MCU——这可能是一个重要的细节。)

之所以这么问，是因为程序员之间似乎对此存在分歧。出于某种原因，跨翻译单元内联函数是否是一种不礼貌的行为(无论您如何操作)，如果是这样，为什么？

假设我跨翻译单元执行内联函数，最不讨厌或最可接受的方式是什么？

将 static 放在标题中似乎效果很好，并且可能是最便携的方法。 pts 在评论中和 buzz 在答案中指出了这一点。从表面上看，我似乎在使用 static 来促进全局使用某些东西——这太疯狂了!但我想我可以更正确地考虑它:内联该函数的每个函数都有自己的静态副本，就好像它在每个相应的 C 文件中定义为 static inline 一样。如果这种理解是正确的，那么行为似乎总是可以预测的——如果翻译单元中有两个同名的函数，链接器必须通知我。

我不确定我对通过头文件中的 extern 声明函数的感觉如何。 6.7.4 中的措辞是在另一个翻译单元中的外部定义是“不禁止的”。

Answer 1

我认为你的 driver.h 应该是这样的:

static inline void foo(void)
{
    <one line>;
}

而你的 bar.c 不需要 extern inline void foo(void); ，只需调用 foo(); ，它就会工作。

至于 If my inline function doesn't get inlined everywhere like it should - would I at least get some sort of linker error warning me that a certain reference couldn't be found
编译时必须显式使用优化选项，然后您将实际内联内联函数。 gcc bar.c -O2 。您可以使用 objdump 来检查代码的汇编代码，您会发现内联函数被内联，而不是调用 foo ，但在那里被内联。