2

我对 C 代码库进行了一些更改，以便它可以在 G++ 下编译。似乎正在工作，有一些烦恼和-fpermissive -fshort-wchar.

出于好奇，我比较了-O2修改前 GCC 构建的可执行文件的剥离大小，以及修改后的 G++ 构建的可执行文件的大小。“之后”大了 32 个字节（在 500K 的二进制文件上）。我很惊喜它是如此接近，但我很想知道为什么如果优化器如此一致，它就不会 100% 一致？但也许是为 strchr 添加重载导致了它。

对我来说还不够重要，不用担心。但后来我决定使用 GCC 进行 C 构建，同时考虑到我的 C++ 兼容性更改。剥离的-O2可执行文件比我更改之前的 C 版本大 4096 字节。

有谁知道为什么这三种尺寸会以这种方式发生，为什么会是这样一个“圆形”数字？C++ 的变化基本上是所有应该优化的东西，无论是在 C 还是 C++ 中。基本上：

  • 引入不透明类型，以便先前在接口中定义为采用 void* 的函数将一致地命名-mangle。通过不透明类型的宏向正确内部类型的本地引入一些强制转换分配

  • 消除了一些旧式 C 函数头定义的实例

  • 为一些以前没有指定链接的全局常量修改到“extern”的链接，暂时容忍将分配保留在标题中，但希望反对这一点

  • 将一些有符号字符更改为无符号字符，将一些无符号长整数更改为无符号整数（但反之亦然）

如果有人对这个优化案例有很好的直觉，那么它将节省我单独退出每组相关更改以查看它们如何影响大小的时间......！

4

1 回答 1

1

请记住：C++ 程序本质上并不比 C 程序大。编译可能需要更多时间，但没有什么可以使 C++ 程序变得更大。

实际上......由于更严格的形式主义和为未定义行为留下的摆动空间，C++ 编译器可能能够比 C 编译器对 C 代码库进行更多优化。

您（又名我）所描述的差异很小。正如@rodrigo 和@MelNicholson 指出的那样，即使是微小的差异也可能会因块大小的舍入而被夸大。因此，单个字节的实际差异可能导致 4096 字节的文件大小差异。

为 C 编译器获取一堆回归测试，将其构建为 C 与 C++ 并查看可执行文件大小是否存在显着差异，然后寻找导致这些差异的模式，这可能会很有趣。如果你（又名我）有时间。它可能会提供数据以反馈到编译器可以改进的地方。但是，在 500K 的可执行文件上，这种大小的单实例差异基本上没有什么可学习的。

于 2014-05-08T23:35:08.657 回答