C++调用静态库方法返回非空指针但赋值后变量为null问题

问题根因 #

你遇到的不是编译器BUG，也和64位特性无关，核心是编译静态链接库和编译主程序时，LLRP::CREADER_EVENT_NOTIFICATION类的定义不一致，导致成员m_pReaderEventNotificationData的内存偏移计算出现了4字节的偏差。
你编译静态库时用到的类定义算出来的成员偏移是24，而实际运行时类实例的内存布局里，该成员的正确偏移是28，所以调用库中预编译的getter方法时，取到了偏移24位置的空值。

可能的诱因 #

• 头文件版本不匹配
  你编译LLRP静态库时用到的头文件，和编译主程序时include的头文件不是同一版本。常见情况是类定义中有宏开关控制的可选成员（比如调试用的额外变量、功能开关控制的字段），编译库和编译主程序时宏定义不一致，导致类布局多了/少了一个4字节的前置成员，偏移刚好差4。
• 内存对齐编译选项不一致
  两边编译时用到的结构体/类对齐参数不同，比如库编译时加了-fpack-struct、#pragma pack等对齐配置，主程序没有对应配置，导致成员偏移计算出现偏差。
• 增量编译缓存问题
  切换平台后没有完全清空之前x86架构下的编译产物，残留的旧头文件、中间目标文件被复用，导致类布局计算错误。
• inline函数的特殊表现
  你用到的getReaderEventNotificationData是inline实现，-O0优化等级下GCC默认不会展开inline函数，会将其作为普通函数调用。如果库中导出了该函数的实现，主程序会直接链接到库中预编译的版本，而不是根据主程序侧的类定义重新生成代码，进一步放大了类布局不一致的问题。

排查方案 #

1. 完全清空所有编译产物：包括LLRP静态库的所有中间文件、主程序的中间文件，重新完整编译一遍，排除增量编译缓存的影响。
2. 校验偏移一致性：在主程序和LLRP库的代码中分别加入编译时断言，确认两边的偏移计算结果是否一致：

#include <cstddef>
static_assert(offsetof(::LLRP::CREADER_EVENT_NOTIFICATION, m_pReaderEventNotificationData) == 28, "类成员偏移不匹配");

如果编译时报断言错误，就可以确认是类定义不一致的问题。
3. 对比两边用到的CREADER_EVENT_NOTIFICATION类定义：重点检查有没有#ifdef/#ifndef包裹的可选成员，编译时的宏参数是否一致。
4. 检查编译选项：确认库和主程序的编译参数中，有没有对齐相关的配置差异，没有特殊需求的话保持两边编译参数完全一致。

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