c - 这是跨翻译单元内联函数的合理技巧吗？

Question

我正在编写对性能敏感的代码，这确实需要我强制内联某些函数调用。

对于通过 header 在翻译单元之间共享的内联函数，通常必须将函数定义放在 header 文件中。我不想那样做。其中一些函数对不应在 header 中公开的复杂数据结构进行操作。

我通过简单地将所有 .h 和 .c 文件一次包含到一个 .c 文件中来解决这个问题，因此只有一个翻译单元。 (这会减慢重新编译的速度，但影响不大。)

这将是“问题已解决”，但它消除了当一个 C 文件中的函数调用另一个本应私有(private)的 C 文件中的函数时出现错误的情况，我希望在这种情况下出现错误。因此，我有一个单独的 Makefile 条目执行“正常”构建，只是为了检查这种情况。

为了强制声明为内联的函数在“正常”构建中很好地运行，我实际上定义了一个宏，may_inline，它用于内联属性通常所在的位置。对于正常构建，它被定义为空，而对于优化构建，它被定义为“内联”。

这似乎是一个可以接受的解决方案。我能看到的唯一缺点是我不能在具有相同原型(prototype)的不同 .c 文件中拥有私有(private)函数，但到目前为止，这对我来说并不是什么大问题。

另一种可能的解决方案是使用 GCC's Link-Time Optimization ，这应该允许跨翻译单元内联。不过，这是一项新功能，我不相信它总是按照我想要的方式内联。此外，我只能让它处理琐碎的问题，而不是我的实际代码。

这是可以接受的黑客行为，还是我在做一些非常愚蠢的事情？我以前从未见过这种做法，这让我有点紧张。

Answer 1

Unity build 是一种绝对有效的方法，并且自古以来就在行业中广泛使用(参见例如 this post )。最新版本的 Visual Studio 甚至提供了 builtin support为他们。

LTO 的缺点是即使在同一平台的编译器之间也不可移植。