Question

我正在解析一个字节流，一旦收到，就形成一个uint8数组。事先已知数组内容应该是什么，可以是整数，字符串或浮点数。所需要的只是将数据重新解释为这些类型。 Float虽然引起了我的担忧。

我的问题，以下结构是否会按预期运行而不会遇到任何意外？（内存别名，填充，字节顺序等）如果没有，那么用尽可能少的代码实现这一目标的最佳方法是什么？

union BytesToFloat{
    float f;
    uint8 bytes[4];
}

作为背景，这些数据来自保存数据，因此计算机写入数据的可能性与读取数据的计算机不同。

修改的

在阅读其中一篇关于字节序的评论之后，这种结构和帮助功能是否会更合适，或者将是一个问题（或者除此之外还有其他问题）

union IntToFloat{
    float f;
    uint32 i;
};

uint32 CharToLong(unsigned char * c){
    uint32 val = c[0];
    val <<= 8;
    val |= c[1];
    val <<= 8;
    val |= c[2]; 
    val <<= 8;
    val |= c[3];
    return val;
}

Answer 1

通过将union替换为4，您可以略微提高sizeof(float)的可靠性（理论上比实践更多）。

但是，您必须通过网络面对其他问题。无法保证连接的两端都使用IEEE 754浮点格式（例如，IBM的zSeries大型机）。也不能保证双方使用相同的字节顺序（英特尔架构使用小端，大多数其他架构使用大端）。您需要知道源计算机和目标计算机的字节顺序才能正确解释数据（但IBM使用的与SQL DBMS通信的DRDA协议就像那样，“接收器正确”约定。）

字节序和字节顺序问题是实际问题;浮点格式往往不是问题，除非你期望与大型机系统一起使用（它们往往是IEEE 754的保留，主要是因为它们的格式在IEEE 754标准化之前已经解决）。

通常，发送数据的最佳方式是使用普通的text格式。它具有易于调试的优点，并且避免了许多（但不是全部）数字表示的难题。但是，如果您的主协议是二进制的，将它更改为浮点文本会很奇怪。

Answer 2

是的，可能会有惊喜。在两端。

该代码的工作方式将是在读写时定义的实现。

从好的方面来说，传输介质（网络或磁盘）通常很慢，因此添加代码以使读/写确定性不会对性能产生重大影响。

另一个好处是代码很少需要在任意平台上运行。确保您所支持的每个平台上正在进行的工作都很有效。

Float和一组unsigned char之间的联合？

2 个答案: