17370845950

只有POD结

构体才能安全memcpy；需满足无虚函数、无非静态成员函数、无用户定义构造/析构/赋值、所有成员也均为POD，否则须手写序列化逻辑。

直接 memcpy 可能出问题，先确认结构体是否满足 POD

不是所有结构体都能安全 memcpy 成二进制流。C++ 要求类型是 POD（Plain Old Data）：不能有虚函数、非静态成员函数、私有/保护非静态数据成员、用户定义构造/析构/赋值函数，且所有成员本身也必须是 POD。

常见踩坑点：

• 结构体里加了 std::string 或 std::vector → 直接 memcpy 会把指针地址写进去，反序列化后读的是野指针
• 用了 #pragma pack(1) 但没在接收端用同样对齐 → 字节序和偏移错乱
• 结构体含浮点数或指针，在不同平台（如 x86 vs ARM）上可能因 ABI 差异导致位宽或字节序不一致

简单 POD 结构体：用 reinterpret_cast + memcpy 最快

若确认结构体是 POD（比如纯 C 风格的 struct Packet { uint32_t len; uint16_t id; char data[64]; };），可直接转为 char* 流：

Packet pkt = {1024, 123, "hello"};
char buf[sizeof(Packet)];
memcpy(buf, &pkt, sizeof(Packet));
// 发送 buf，或存入文件

反序列化同理：

Packet* p = reinterpret_cast(buf);
// 注意：buf 生命周期必须长于 p 的使用期；不要用 static_cast 替代 reinterpret_cast

关键提醒：

• 发送前确保 sizeof(Packet) 在收发两端完全一致（检查编译器、打包指令、对齐方式）
• 避免跨平台直接传浮点字段——float 在 IEEE754 下虽通用，但某些嵌入式平台不保证
• 别对含 bit-field 的结构体这么做，位域布局无标准保证

含 STL 容器或非 POD 成员？必须手写序列化逻辑

例如结构体带 std::string name 和 std::vector ids，就不能整体拷贝。得拆开处理：

• 先写固定头：如 uint32_t name_len，再写 name.data() 的原始字节
• 再写 uint32_t ids_size，然后逐个写 ids[i]（注意 endianness）
• 接收端严格按相同顺序读：先读长度，再 malloc/resize，再读数据块

示例片段（简化版）：

void serialize(const MyStruct& s, std::vector& out) {
    uint32_t len = htonl(static_cast(s.name.size())); // 网络序
    out.insert(out.end(), reinterpret_cast(&len), 
               reinterpret_cast(&len) + sizeof(len));
    out.insert(out.end(), s.name.begin(), s.name.end());
}

注意：htonl / ntohl 仅对整数有效，且只解决字节序，不解决大小端对齐差异（如 long 在 Windows 和 Linux 可能是 4 或 8 字节）。

跨语言或长期存储？别手撸，用 Protocol Buffers 或 flatbuffers

如果结构体要被 Python/Java 读取，或需向前兼容（比如新增字段不影响旧版本解析），硬编码二进制格式很快失控。这时候：

• protobuf：定义 .proto 文件，生成 C++ 类，自带 SerializeToArray 和 ParseFromArray
• flatbuffers：零拷贝、无需解析步骤，适合高频低延迟场景，但要求结构体字段全为 POD 或 flatbuffers 内置类型
• 避免用 boost::serialization：它依赖运行时类型信息和 operator

真正容易被忽略的一点：即使你控制全部代码，只要未来可能加日志回放、网络协议升级、或导出数据给数据分析脚本，二进制格式就必须带 magic number + version 字段 —— 否则某天 sizeof(MyStruct) 变了，老数据就永远读不出来了。