#if defined预处理对类成员对齐的影响 生成SO8字节差异原因

• 差异本质：0x7225b9位置的指令是operator new（对应符号_Znwm）的入参配置，edi寄存器存储的值就是要分配的webrtc::VideoStreamEncoder类对象总大小：
  • liba.so中为0xfb8（十进制4024）
  • libb.so中为0xfc0（十进制4032）
    两者差值恰好为8字节。
• 差异来源为C++类内存对齐规则，和新增的头部成员is_perf_adaption_avalaible_直接相关。64位环境下该类的最大对齐数为8字节（由内部的std::map、指针类成员决定），编译器会按照成员声明顺序，为每个成员匹配对齐要求，不足的位置自动填充padding：
  1. liba版本头部成员布局：
     • 偏移0：int latest_encode_usage_（4字节，4字节对齐）
     • 偏移4：int perf_target_framerate_（4字节，4字节对齐）
     • 偏移8：std::map pre_dlbitrate_（8字节对齐要求，刚好落在8的整数倍地址，无额外padding）
       到map起始位置共占用8字节。
  2. libb版本头部成员布局：
     • 偏移0：bool is_perf_adaption_avalaible_（1字节，1字节对齐）
     • 偏移1-3：3字节自动填充padding（满足后续int成员的4字节对齐要求）
     • 偏移4：int latest_encode_usage_（4字节，4字节对齐）
     • 偏移8：int perf_target_framerate_（4字节，4字节对齐）
     • 偏移12-15：4字节自动填充padding（满足后续std::map成员的8字节对齐要求）
     • 偏移16：std::map pre_dlbitrate_
       到map起始位置共占用16字节，较liba版本多出8字节的对齐padding。
• 由于增加的8字节偏移刚好是类最大对齐数的整数倍，后续所有成员（包括map本身、is_screen_share_、类内其他原有成员）的相对布局、对齐规则不会产生额外的大小开销，因此整个类的总大小刚好增加8字节，与反汇编观测结果完全吻合。
• 验证方式：
  • 编译两个版本代码时，直接打印sizeof(webrtc::VideoStreamEncoder)，数值会和反汇编中edi寄存器的入参完全一致。
  • 通过offsetof宏打印pre_dlbitrate_的成员偏移，可观测到liba版本偏移为8，libb版本偏移为16，直接定位对齐padding的位置。

内容的提问来源于stack exchange，提问作者Cat Tom