24位与8位无符号整数打包：Union方案可行性及与位域差异

我正在寻找无需移位操作即可将24位和8位无符号整数打包为32位的最优方案，首先想到的是如下简单Union实现：

union {
    uint32_t u24;
    uint8_t u8[4]; // use only u8[3]
}

但该方案因系统字节序问题存在未定义行为，因此我采用C++20的std::endian特性在编译时检测字节序，实现了如下方案：

#include <bit>
struct UnionTest {
    union {
        uint32_t u24;
        uint8_t u8[4];
    };
    
    inline constexpr uint8_t get_u8_index() const noexcept {
        if constexpr (std::endian::native == std::endian::little) return 0;
        else if constexpr (std::endian::native == std::endian::big) return 3;
        else // 处理异常字节序情况
    }
};

// 使用示例：
int main() {
    UnionTest test;
    test.u24 = 0xffffff;
    test.u8[test.get_u8_index()] = 0xff;
}

假设u24始终写入不超过24位的值，我仅关注该方案的可行性；此外还有一种位域实现方式：

struct UnionTest {
    uint32_t u24 : 24;
    uint32_t u8 : 8;
}

但该方式可能占用64位内存（多数情况下应为32位）。现提出两个问题：
A）上述Union方案的性能表现及是否存在未定义行为？
B）该Union方案与C++位域的实际差异是什么？

A）Union方案的性能与未定义行为 #

未定义行为分析 #

C++标准中，union的类型双关（写入一个成员后读取另一个不同类型成员）通常属于未定义行为，但存在例外：若两个成员是标准布局类型，且其中一个为字符类型数组（如这里的uint8_t u8[4]），则通过字符数组访问union对象的底层字节是被允许的。

你的方案中，先写入u24再通过u8数组修改对应字节，完全符合这个例外规则——uint8_t属于字符类型，访问数组元素等价于直接操作对象的底层字节，不会触发未定义行为。同时std::endian是编译时判断，get_u8_index()作为constexpr函数，返回值在编译阶段即可确定，不会引入运行时开销。

性能表现 #

该方案性能几乎等同于直接内存操作：

• 写入u24是单次32位内存写入；
• 修改u8数组元素是单次8位内存写入；
• 无移位、掩码等算术运算，完全是直接内存访问，任何架构下都能达到最优性能，编译器会直接生成对应的内存读写指令，无额外开销。

B）Union方案与C++位域的实际差异 #

内存布局确定性 #

• Union方案：内存布局由系统字节序决定，但通过std::endian做了编译时适配，能精准控制8位值存于32位的最高字节（大端）或最低字节（小端）。只要保证u24仅写入24位数据，剩余字节可安全修改，内存总大小固定为32位（uint32_t的大小）。
• 位域方案：C++标准对位域内存布局几乎无强制规定：
  • 位域的顺序（高位在前/低位在前）由编译器和平台决定；
  • 同基类型的位域是否打包到同一内存单元，也由编译器决定；
  • 你编写的uint32_t u24:24; uint32_t u8:8;多数编译器会打包为32位，但不排除部分编译器将其分到不同32位单元，导致结构体大小变为64位，完全无确定性。

操作方式与性能 #

• Union方案：直接操作内存字节，无额外运算，性能最优；修改8位值时直接写入对应字节，无需考虑掩码或移位。
• 位域方案：访问位域时，编译器会自动生成掩码、移位指令提取/设置对应位段。比如写入u8时，编译器可能先读取整个32位值，掩码掉原有8位，再合并新值写回，比Union方案多了读-改-写步骤，性能略差。

类型安全性与可读性 #

• Union方案：需手动处理字节序，代码需明确对应字节位置，可读性稍弱，但操作是明确的内存访问，类型定义清晰。
• 位域方案：代码可读性更强，直接用u24和u8表示对应位段，但因布局不确定，跨平台移植性差，部分编译器可能对位域访问做额外安全检查，带来微小性能损耗。

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