函数实现在:file.h与file.cxx中

对于编译器来说,来自.cxx文件或.h文件的输入之间没有区别,这些文本被编译成相同的翻译单元。

我们通常这样做的主要原因 不 把代码放在头文件中,是为了避免重复的对象,当一个给定的头被多个.cxx文件使用时,这些对象会在链接器的级别上发生冲突。

可能您将内联函数与宏混淆了,因为在宏的情况下,宏本质上是一个预处理指令,因此不存在链接器时间冲突的风险,即使/如果相同的头包含不同翻译单位的多次。

当然,可以在头(或其他地方)中定义函数,以指示编译器系统地内联对函数的调用,在这种情况下,链接时也没有冲突。然而,这需要特殊的语法,并且仅仅是由代码来自include文件或cpp文件(如问题所示)这一事实所暗示的。

现在,为了回答这个问题,将所有这些代码从头文件移到cpp文件中,本身不应该对二进制文件的大小或性能产生太大的影响。
显然,如果头文件中的函数定义不是显式内联的,那么每个生成的不同exe/dll文件必须只有头文件的一个用户(否则在链接时会有重复的用户),因此该文件在任何方向都不会改变。
在性能方面,随着硬件的总体性能提高,即使以前的内联函数现在被正常调用,这种情况也应该从性能上看是不被注意的,除了逻辑迭代次数非常多的特定紧循环之外。

好主意,迁移,不要宏/内联香蕉

在传统的EARS中,过程调用机器操作相当昂贵,因此C和C++的宏处理特性,以及 inline 功能有时很重要。

随着时间的推移,单个机器的操作不再是性能问题。

事实上,情况有点颠倒了。将一个过程扩展到任何地方的内联代码对于最小化已经由CPU过程调用机器操作优化的过程都没有什么好处,但是通过浪费宝贵的内环缓存空间和大量相同函数的副本来破坏缓存。

我说:定义真正的函数。CPU会处理得很好。

您的应用程序似乎是一个时代的产物,在这个时代,将代码分解成直线执行很流行。我认为这部分可以追溯到最初的VAX 11/780,它是第一个流行的Unix 32位系统,并且在一段时间内定义了一个1 mips的CPU,但是过度的使用和微编码 calls 指令要求17我们执行。对, 17X 这是一个正常的操作。这不再是真的,但BSD编码风格,合理地试图处理VAX的奇怪仍然坚持到今天。(嘿,我是BSD迷,但我们今天不需要宏中的所有内容。)

因此,要回答您的确切问题:您将通过将这些例程迁移到单独链接的.cxx模块中来获得更好的缓存性能。去做吧。

头文件的目的是包含可能包含在多个源文件中的定义。放在头文件中的代码包含在源文件中,然后编译。就编译代码而言,它与该头的整个内容是源代码的一部分一样。

将代码放入头文件或源(CXX)文件是惯例。编译器不会根据其所在位置更改行为。

您可以在“大规模C++软件设计”第6章“绝缘”中找到答案。

包含的可更改、添加或删除的实现细节 如果不强迫客户重新编译,就说是绝缘的。