我对C代码库进行了一些更改，以便它可以在G ++下编译。似乎工作，有些烦恼和-fpermissive -fshort-wchar的黑客。
出于好奇，我在更改之前比较了GCC构建的可执行文件的剥离-O2大小，以及在我的更改之后构建了G ++构建的可执行文件。 “after”大于32字节（在500K-ish二进制上）。令我惊喜的是，它如此接近，但却想知道为什么如果优化器 一致，它不会100％一致？但也许有关添加overload for strchr引起它的事情。
对我来说不够重要。但后来我决定使用GCC进行C版本考虑我的C ++兼容性更改。剥离-O2可执行文件比我更改之前的C版本 4096字节。
有没有人直截了当为什么这三种尺寸会以这种方式发生，以及为什么会出现这种“圆形”数字呢？ C ++的变化基本上都是应该优化的东西，无论是在C还是C ++中。基本上是：
引入opaque类型，以便先前在接口中定义为void *的函数将一致地命名为mangle。通过opaque类型的宏向本地人介绍了一些演员分配到适当内部类型的本地
消除旧式C函数头定义的几个实例
修改了一些未指定链接的全局常量与“extern”的链接，暂时容忍keeping the assignments in the headers但希望反对
将一些有符号的字符更改为无符号字符，将一些无符号长字更改为无符号字符（但反之亦然）
如果有人对这种优化案例有很好的直觉，那么它可以节省我单独退出每组相关变更的时间，看看它们如何影响大小......！
答案 0 :(得分：1)
请记住：C ++程序本质上不比C程序大。编译可能需要更多时间，但没有什么能够使C ++程序变得更大。
实际上......由于undefined behavior更加严格的形式主义和摆动空间，C ++编译器可能能够在C代码库上进行比C编译器更多的优化。
（a.k.a.me）所描述的差异很小。正如@rodrigo和@MelNicholson指出的那样，即使是微小的差异也可能被块大小舍入所夸大。因此，单个字节的实际差异可能导致4096字节的文件大小差异。
为C编译器获取一堆回归测试可能会很有趣，将其构建为C与C ++并查看可执行文件大小是否存在任何显着差异，然后查找导致这些差异的模式。如果你（a.k.a.me）有时间。它可能会提供数据反馈到编译器可以改进的地方。但是，基于500K可执行文件的这种大小的单实例差异基本上没有任何东西可以学习。