只有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,或存入文件
反序列化同理:
立即学习“C++免费学习笔记(深入)”;
Packet* p = reinterpret_cast(buf); // 注意:buf 生命周期必须长于 p 的使用期;不要用 static_cast 替代 reinterpret_cast
关键提醒:
- 发送前确保
sizeof(Packet)在收发两端完全一致(检查编译器、打包指令、对齐方式) - 避免跨平台直接传浮点字段——
float在 IEEE754 下虽通用,但某些嵌入式平台不保证 - 别对含 bit-field 的结构体这么做,位域布局无标准保证
含 STL 容器或非 POD 成员?必须手写序列化逻辑
例如结构体带 std::string name 和 std::vector,就不能整体拷贝。得拆开处理:
- 先写固定头:如
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) 变了,老数据就永远读不出来了。











