c++ - 我可以使用这种技术来防止违反抗锯齿规则吗？

Question

如果我没记错的话，写入 FastKey::key 然后从 FastKey::keyValue 读取是未定义的行为:

struct Key {
    std::array<uint8_t, 6> MACAddress;
    uint16_t EtherType;
};

union FastKey {
    Key key;
    uint64_t keyValue;
};

但是，有人告诉我，如果我将 char 数组添加到 union 中，则 UB 将被清除:

union FastKey {
    Key key;
    uint64_t keyValue;
    char fixUB[sizeof(Key)];
};

这是真的吗？

编辑

像往常一样，我的理解是错误的。根据我收集到的新信息，我认为我可以获得像这样的 uint64_t 值形式的 key :

struct Key {
    std::array<uint8_t, 6> MACAddress;
    uint16_t EtherType;
};

union FastKey {
    Key key;
    unsigned char data[sizeof(Key)];
};

inline uint64_t GetKeyValue(FastKey fastKey)
{
    uint64_t key = 0;
    key |= size_t(fastKey.data[0]) << 56;
    key |= size_t(fastKey.data[1]) << 48;
    key |= size_t(fastKey.data[2]) << 40;
    key |= size_t(fastKey.data[3]) << 32;
    key |= size_t(fastKey.data[4]) << 24;
    key |= size_t(fastKey.data[5]) << 16;
    key |= size_t(fastKey.data[6]) << 8;
    key |= size_t(fastKey.data[7]) << 0;
    return key;
}

我怀疑这将与原始版本一样快。请随时纠正我。

更新

@Steve Jessop 我实现了一个 quick benchmark测试 memcpy 与我的解决方案的性能。我不是基准测试专家，因此代码中可能存在导致错误结果的愚蠢错误。但是，如果代码是正确的，那么 memcpy 似乎要慢得多。

注意:基准测试似乎是错误的，因为计算快键时间的时间始终为零。我看看是否可以修复它。

Answer 1

不，读取 uint64_t 如果你有一个 Key 对象，仍然有 UB。不是UB的是读取char，因为别名规则中char有一个异常(exception)。添加数组不会将异常传播到其他类型。

编辑中的版本看起来不错(尽管我会使用 unsigned char)，但现在它比仅使用 Key 中的 reinterpret_cast 更复杂* 到 unsigned char* 或 memcpy。