一些想法:
>我可以想到的一个可能的合法用途是当您想要创建一个功能可用而不创建具有外部链接的符号和污染外部命名空间。 (但是,您可以使用一个模糊的前缀名称,如mylib123__foobar,和#define foobar mylib123__foobar在头文件中,所以这个似乎有点iffy)
>您希望某些功能纯粹通过头文件可用,而不需要用户链接库/对象文件。我可以看到这是一个真正的动机,当提供几乎只是数据结构和一些微不足道的代码来处理它们的“库”。事实上,如果数据结构不透明并且意味着被应用程序直接访问,则将与其一起使用的功能放在同一个头文件中(与库中相比)大大降低了在更改数据时/更改数据时的破坏风险结构。
>也许该函数只是一个外部函数的包装器,包装器的工作方式可能取决于调用编译单元中的编译时选项。例如:
static int foobar(int x)
{
return real_foobar(COMPILETIME_PARAMETER, x);
}
你可能会说只是使用宏,但是如果foobar需要通过函数指针来调用预期用途呢?
有了这个说…
在现实中,人们把静态功能放在头文件中的主要原因通常是基于一些十年过去的概念,即通过允许编译器内联函数或者什么来改进性能。大多数这样做的人没有做任何测量。由于现代编译器可以将整个程序作为一个单元进行编译,如果有问题,这在理论上会导致更多的优化可能性,而且由于这是一个有问题的优化开始,所以我真的怀疑将标题放置在性能上。
这个批评尤其适用于OP的“大”静态函数在头文件中的例子。几乎没有一个大功能可以从内联中获益,除非一个常量的参数值允许编译器消除90%的代码或某些东西。 (对于这种极端情况的现实世界的例子,请参阅libavcodec中使用的一些疯狂的内联函数/宏定义:-)