我对 C 代码库进行了一些更改，以便它可以在 G++ 下编译。似乎在工作，有一些烦恼和 -fpermissive -fshort-wchar 的 hack。
出于好奇，我比较了更改前 GCC 构建的可执行文件和更改后的 G++ 构建的可执行文件的剥离 -O2 大小。 “之后”要大 32 个字节(在 500K 左右的二进制文件上)。我很惊喜它是如此接近，但懒惰地想知道为什么如果优化器是 那个 一致它不会是 100% 一致？但也许是关于添加 overload for strchr造成了。
对我来说还不够重要，不用担心。但后来我决定使用 GCC 进行 C 构建，考虑到我的 C++ 兼容性更改。剥离的 -O2 可执行文件比我更改之前的 C 版本大 4096 字节。
有没有人有直觉，为什么这三种尺寸会以这种方式发生，为什么会是这样一个“整数”？ C++ 的变化基本上是所有应该优化的东西，无论是在 C 还是 C++ 中。基本上:
引入不透明类型化，以便之前在接口(interface)中定义为采用 void* 的函数可以一致地命名。通过不透明类型的宏向适当的内部类型的局部变量引入了一些对局部变量的强制转换
消除了一些旧式 C 函数头定义的实例
将之前未指定链接的一些全局常量的链接修改为“extern”，暂时容忍keeping the assignments in the headers但希望对此提出异议
将一些有符号字符更改为无符号字符，并将一些无符号长整型更改为无符号整数(但绝不会相反)
如果有人对这个优化案例有很好的直觉，那么它会节省我单独退出每组相关更改以查看它们如何影响大小的时间......!
最佳答案
请记住:C++ 程序本质上并不比 C 程序大。编译可能需要更多时间，但并没有什么本质上会使 C++ 程序变大。
实际上...由于更严格的形式主义和留给 undefined behavior 的回旋余地 | ，C++ 编译器可能能够对 C 代码库进行比 C 编译器更多的优化。
您(又名我)描述的差异很小。正如@rodrigo 和@MelNicholson 指出的那样， block 大小四舍五入可能会夸大即使是微小的差异。因此，单个字节的实际差异可能导致 4096 字节的文件大小差异。
获取 C 编译器的一系列回归测试，将其构建为 C 与 C++ 并查看可执行文件大小是否存在任何显着差异，然后寻找导致这些差异的模式可能会很有趣。如果你(又名我)有时间。它可能会提供数据以反馈到编译器可以改进的地方。但是，对于一个 500K 的可执行文件，从这种大小的单一实例差异中基本上无法学到任何东西。
关于c++ - 在 C++ 兼容性更改后，G++ 生成的二进制文件比 GCC 小，但比之前的二进制文件稍大？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13919228/