我有一个文件funcs.h，其中有函数声明：

然后我有一个文件funcs.c，其中有函数的实现：

然后在我的主文件中，我main.c尝试在代码中的某处使用。但是，当我编译我的程序并查看二进制文件时，该函数似乎被编译为一个常规的单独函数，并且像任何其他常规函数一样被调用，而不是作为内联嵌入。#includefuncs.hsome_func()

为什么会发生这种情况，有没有办法强制实际内联呢？（当然，除了只使用#define宏而不是函数的选项。）

在关于函数声明中的关键字的许多争论inline中，有人会指出它实际上会在某些情况下使您的程序变慢——如果我是正确的话，主要是由于代码爆炸。我自己在实践中从未遇到过这样的例子。什么是实际代码，其中使用inline可能会损害性能？

C Example

bb.c:

main.c:

aa.h:

bb.h:

C Result

Compiled with clang main.c bb.c:

C++ Example

b.cpp:

main.cpp:

a.hpp:

b.hpp:

C++ Result

The above compiles fine with clang++ main.cpp b.cpp and the output to the program is:

Questions

1. Why does the duplicate error not occur with the C++ version?

2. Does the fact that the function void a::doit() is defined in the header file rather than a source file mean that the compiler will automatically inline the function?

我在 Scott Meyers 的 Effective C++ 书中读到：

当你内联一个函数时，你可以使编译器对函数体执行上下文特定的优化。对于正常的函数调用，这种优化是不可能的。

现在的问题是：什么是特定于上下文的优化以及为什么它是必要的？

我正在使用Code Composer Studio，我需要内联一些函数。所以我把它们放在头文件中（或者放在头.inl文件引用的文件中，两种方式）并尝试构建我的项目。

当我提高优化级别时，问题就来了。该项目在没有优化的情况下成功构建，（关闭或无）但链接器无法链接它们并返回：

有没有人遇到过类似的问题？

是因为我没有在编译器选项中使用某种标志吗？

我有一个 1 行inline函数，它是我的代码中热点的一部分。我想看看将其更改为宏是否有益。作为一个函数写作我不必担心副作用。但是我如何为此编写一个没有副作用的宏呢？

static inlinea和extern inline普通inline函数有什么区别？

我已经看到了一些模糊的解释。据我了解，static inline不仅仅是一个inline函数，它只能在某个文件中被引用，因为static关键字通常意味着。我猜也一样extern inline，这与extern变量的解释不同。任何答案将不胜感激！

In my question I originally asked these four questions

1. In C99 compilers, is the behavior of inline implementation defined when it comes to inlining across translation units?
2. If so, should it be avoided?
3. Is there some other generally accepted way of doing this?
4. If my inline function doesn't get inlined everywhere, would I at least get some sort of linker error?

After my OP I discovered that the first question has been discussed at length already in the following threads:

• How to declare an inline function in C99 multi-file project?
• Is inline without static or extern ever useful in C99?

There are more threads on this topic, but these two seemed to hit the nail on the head.

So, based on these two discussions we can see that the answer to question 1 is YES. Compilers definitely have some freedom W.R.T. how they handle the inline specifier.

We also see that for this to work inline functions must be defined in a header.

Then beyond that the following options exist:

1. The function definition in the header may have a static specifier.
2. If the header definition does not have a static specifier, it may be declared via extern in some common header file that all C files calling the function will also #include.
3. If methods 2 and 3 are not used, method 4 would be to declare this inline function via extern in every C file that wishes to call it.

So, now that all of that explanation is out of the way, I would like to refocus this question on my original items #2 and #3 – should I even be doing this, and if so what's the most acceptable way?

Should I be doing this - or should this be avoided as much as possible?

Consider my application – I have a one line function in a driver that is called frequently (≈ several hundred times a second), but only from 3 or 4 other places. So using inline will not contribute to code bloat – in fact the result will be negligible. Gregory Pakosz outlines when to use an inline function and when not to nicely in this answer. So therefore, the answer would be very clear if this were one function being used in one translation unit. But that's not what I am asking.

In this situation I do not need to inline this function. But should I? I will probably never notice any performance difference because I inlined just this one function. But I am trying to figure out if I should make this my general practice in all similar situations. If I inline short functions that are frequently called more aggressively I may see a performance improvement. (My runtime environment is a low power 16bit RISC MCU – that's probably an important detail.)

The reason for asking is this is because there seems to be a disagreement among programmers about this. Is it bad etiquette for some reason to inline functions across translation units (no matter how you do it), and if so, why?

Assuming I do inline functions across translation units, what's the least detestable or most acceptable way?

Putting static in a header seems to work well and may be the most portable way to do it. This was pointed out by pts in the comments and by and buzz in the answers. On the surface it seems like I am using static to facilitate using something globally – which is nuts! But I suppose I can more correctly think about it like this: every function that inlines this function will have its own static copy as if it were defined in each of the respective C files as static inline. If that understanding is correct then it seems like the behavior would always be predictable – the linker would have to give me notice if there are two functions with the same name in a translation unit.

I am not sure how I feel about declaring a functions via extern in a header. The wording in 6.7.4 is that external definition in another translation unit is “not forbidden”.

在玩优化设置时，我注意到一个有趣的现象：带有可变数量参数 ( ...) 的函数似乎从来没有被内联。（显然这种行为是特定于编译器的，但我已经在几个不同的系统上进行了测试。）

例如编译如下小程序：

似乎总是会导致test生成的可执行文件中出现一个（可能是损坏的）符号（在 MacOS 和 Linux 上的 C 和 C++ 模式下使用 Clang 和 GCC 进行测试）。如果修改签名 oftest()以获取传递给 的纯字符串，则两个编译器都会按照您的期望printf()从向上内联该函数。-O1

我怀疑这与用于实现可变参数的巫毒魔法有关，但是这通常是如何完成的对我来说是个谜。谁能告诉我编译器通常如何实现可变参数函数，以及为什么这似乎阻止了内联？

假设我们有以下代码：

对于上面的代码，我们有三种可能的情况：

1. 一个将被内联，两个不会
2. 一和二将被内联
3. 一和二不会被内联（因为我们取了函数的地址）

现在我想知道以上哪种情况是真的？