C++/Qt 工业协议中的数据类型的选择原则和典型用法。
一、类型对比总结
| 类型 | 符号 | 大小 | 本质 | 在工业协议中的角色 |
|---|---|---|---|---|
char | 由实现定义(通常有符号) | 1 字节 | C++ 内建字符类型 | 不推荐用于字节操作,(范围 –128 ~ 127)存 ≥128 的值会溢出/符号扩展 |
unsigned char | 无符号 | 1 字节 | C++ 内建无符号字节类型 | 单字节的首选类型,0~255 无歧义 |
uint8_t | 无符号 | 1 字节 | C++11 标准 8 位整型 | 与unsigned char等价,可跨非 Qt 项目 |
quint8 | 无符号 | 1 字节 | Qt 的typedef unsigned char quint8 | Qt 项目中等同于 |
| unsigned short | 无符号 | ≥2 字节(通常 2 字节) | C++ 内建无符号字节类型 | 可与uint16_t混用,但大小不完全保证严格 16 位 |
uint16_t | 无符号 | 2 字节 | C++11 标准 16 位整型 | 存放 16 位寄存器值(Modbus、Profibus 等) |
quint16 | 无符号 | 2 字节 | Qt 的unsigned short(保证 16 位) | 同上,Qt 专用 |
QByteArray | 内部char,但逻辑无符号 | 动态 | Qt 字节数组容器 | 整个报文的承载者:拼接、存储、传输 |
二、核心区别与选用原则
1. 字节类型(1 字节)
永远不要用
char来存储原始字节,因为它的符号性是平台相关的。0x80可能变成-128,在比较和位运算中产生错误。首选
unsigned char或uint8_t或quint8,三者本质相同:
unsigned char byte1 = 0x80; // C 风格 uint8_t byte2 = 0x80; // 标准 C++ 风格 quint8 byte3 = 0x80; // Qt 风格- 在纯 Qt 项目中用
quint8风格一致;需要跨非 Qt 环境时用uint8_t
2. 双字节类型(16 位)
unsigned short是 C++ 内建类型,标准只规定“至少 16 位”,但现代平台都是 16 位。Qt 的quint16就是unsigned short,并明确保证为 16 位。uint16_t是 C++11 标准类型,严格 16 位,无符号。在跨平台或非 Qt 代码中更安全。工业协议中两者可互换,但建议统一风格:Qt 项目用
quint16,通用代码用uint16_t。
注意:不要混用unsigned short和uint16_t去接收同一个变量,因为理论上unsigned short可能大于16位(极少见),不过实践中没问题。
3. 字节容器
QByteArray是字节流的理想容器,提供自动内存管理、拼接、索引、与 C 接口互操作的能力。内部存储使用
char*,但 Qt 承诺将其内容视为无符号字节,并提供constData()、data()等函数。读取单字节时强转成quint8或unsigned char以避免符号扩展:quint8 val = static_cast<quint8>(buffer.at(0));
三、工业协议中的黄金组合
下面是用这些类型构建一个“写浮点数”的典型流程(西门子 S7、Modbus 等场景):
// 1. 原始数值 float realVal = ui->write_real_value->text().toFloat(); // 2. 位模式复制到32位无符号整数(平台字节序无关,只复制二进制) quint32 raw; std::memcpy(&raw, &realVal, sizeof raw); // 3. 手动将 raw 转为 4 字节大端,放入 payload QByteArray payload; payload.resize(4); // 高字节在前(大端) payload[0] = static_cast<char>((raw >> 24) & 0xFF); payload[1] = static_cast<char>((raw >> 16) & 0xFF); payload[2] = static_cast<char>((raw >> 8) & 0xFF); payload[3] = static_cast<char>( raw & 0xFF); // 4. 构造完整报文 QByteArray telegram; // 功能码(单字节,0x01 安全,不会出现符号问题) telegram.append(static_cast<char>(0x01)); // 起始地址 264 (0x0108) 手动拆成大端两字节 quint16 startAddr = 264; telegram.append(static_cast<char>((startAddr >> 8) & 0xFF)); // 高字节 0x01 telegram.append(static_cast<char>( startAddr & 0xFF)); // 低字节 0x08 // 追加浮点数据(已经是4字节大端) telegram.append(payload); // 后续计算校验、发送...解析响应时同理:
// 假设 response 是从 PLC 收到的 QByteArray,offset 是浮点数据起始偏移 const unsigned char *ptr = reinterpret_cast<const unsigned char*>(response.constData()) + offset; // 1. 手动将两个 16 位寄存器从大端转为主机字节序 quint16 regHi = (static_cast<quint16>(ptr[0]) << 8) | ptr[1]; // 高16位 quint16 regLo = (static_cast<quint16>(ptr[2]) << 8) | ptr[3]; // 低16位 // 2. 组合成 32 位,注意 regHi 在高位 quint32 combined = (static_cast<quint32>(regHi) << 16) | regLo; // 3. 位模式复制回 float float result; std::memcpy(&result, &combined, sizeof result); /************************************************************************ quint16 regHi = (static_cast<quint16>(ptr[0]) << 8) | ptr[1]; // 高16位 quint16 regLo = (static_cast<quint16>(ptr[2]) << 8) | ptr[3]; // 低16位 1. 为什么不是“转换成 8 位”? 工业协议中,一个 16 位寄存器本身就是 16 位的数据,本来就应该用 16 位类型承载。 从字节流解析的过程,就是从两个 8 位“原料”组装成一个 16 位“成品”,而不是把 16 位“压缩”成 8 位。 2. 整个思路 text 字节流: [ptr[0]] [ptr[1]] ← 两个 8 位 └─高8位─┘ └─低8位─┘ ↓ 拼接 regHi (16位) ptr[0] 贡献高 8 位,ptr[1] 贡献低 8 位,组合起来就是原本传输的 16 位寄存器值。这个值自然要存在 quint16 变量里,后续才能继续左移 16 位组合成 32 位浮点的位模式。 ************************************************************************/