跨平台解决C++带填充结构体直接读取18字节文件数据问题

方案1：手动序列化/反序列化（最稳妥） #

这是跨平台场景下的首选方案，完全绕开编译器对齐规则，同时还能解决字节序差异问题：

#include <cstdint>
#include <fstream>

struct Test {
    uint8_t a;
    uint8_t b;
    uint8_t c;
    uint16_t d;
    uint16_t e;
    uint8_t f;
    uint16_t g; 
    uint16_t h; 
    uint16_t i; 
    uint16_t j; 
    uint8_t  k;  
    uint8_t  l;
};

bool readTestFromFile(std::ifstream& file, Test& out) {
    // 逐个读取单字节成员
    file.read(reinterpret_cast<char*>(&out.a), sizeof(out.a));
    file.read(reinterpret_cast<char*>(&out.b), sizeof(out.b));
    file.read(reinterpret_cast<char*>(&out.c), sizeof(out.c));
    file.read(reinterpret_cast<char*>(&out.f), sizeof(out.f));
    file.read(reinterpret_cast<char*>(&out.k), sizeof(out.k));
    file.read(reinterpret_cast<char*>(&out.l), sizeof(out.l));

    // 处理16位成员，需根据文件固定字节序转换（示例假设文件是大端）
    auto read_uint16 = [&file]() {
        uint16_t temp;
        file.read(reinterpret_cast<char*>(&temp), sizeof(temp));
        return ntohs(temp); // 主机字节序转网络字节序，反之用htons
    };

    out.d = read_uint16();
    out.e = read_uint16();
    out.g = read_uint16();
    out.h = read_uint16();
    out.i = read_uint16();
    out.j = read_uint16();

    return file.good();
}

这种方式完全不依赖编译器行为，是生产环境中最可靠的做法。

方案2：跨编译器打包结构体（谨慎使用） #

通过宏封装不同编译器的打包属性，强制结构体按1字节对齐：

#ifdef _MSC_VER
#define PACKED __declspec(align(1))
#else
#define PACKED [[gnu::packed]]
#endif

PACKED struct Test {
    uint8_t a;
    uint8_t b;
    uint8_t c;
    uint16_t d;
    uint16_t e;
    uint8_t f;
    uint16_t g; 
    uint16_t h; 
    uint16_t i; 
    uint16_t j; 
    uint8_t  k;  
    uint8_t  l;
};

注意事项：

• 打包后的结构体可能引发性能问题，部分架构下不对齐的内存访问会变慢甚至触发硬件异常
• 不同编译器对打包属性的实现存在细微差异，需多平台测试
• 仍需处理字节序问题，跨平台主机字节序可能不同

方案3：调整成员顺序减少填充（无法彻底解决） #

编译器填充是为了满足成员的自然对齐要求，比如uint16_t需要2字节对齐。调整成员顺序把同类型数据放在一起，能减少填充但无法保证跨平台大小一致：

struct Test {
    uint8_t a;
    uint8_t b;
    uint8_t c;
    uint8_t f;
    uint8_t k;
    uint8_t l;
    uint16_t d;
    uint16_t e;
    uint16_t g; 
    uint16_t h; 
    uint16_t i; 
    uint16_t j; 
};

该方案仅能优化内存占用，无法保证结构体布局和文件数据完全匹配，不适合直接映射文件内容。

关于“凑32字节”方案的说明 #

这个思路不可行：即使总大小凑到32字节，编译器依然会在成员间插入填充以满足自然对齐要求，最终结构体的内存布局还是和文件的18字节数据不匹配，读取后成员值会错位。

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