QByteArray访问与严格别名规则：代码是否存在未定义行为？

你提到的严格别名规则确实容易绕晕人，咱们一步步拆解你的问题：

1. 第一段代码的未定义行为判定 #

首先可以明确：第一段代码属于未定义行为（UB）。

核心原因就是严格别名规则——简单说，C++标准规定，程序不能通过一个和对象实际类型不兼容的指针来访问对象（只有少数例外，比如用char*去读取任何类型的字节是允许的，但反过来不行）。你的QByteArray缓冲区实际存的是char数组，却直接把它转成Alias*去访问成员a，相当于用Alias类型的指针“偷看”char类型的对象，完全违反了严格别名规则。这种情况下编译器可能会做出各种匪夷所思的优化，比如直接跳过这段访问、生成错误的指令，导致程序行为完全不可预测。

2. std::launder能否解决问题？ #

很遗憾，std::launder在这里帮不上任何忙。

std::launder的本质是个“编译器提示”，用来告诉编译器：这个指针指向的对象可能已经被重新构造过了，别再用之前缓存的对象信息做优化。但你的问题里，Alias类型的对象从来没有在这个缓冲区里被构造过（你明确说没用到placement-new），相当于你指着一块空地皮说“帮我刷新一下这里的房子信息”，根本没有可操作的合法对象，用了std::launder之后依然是UB。

3. 安全的替代方案：memcpy是最优选择 #

要安全地从char缓冲区获取Alias类型的数据，最稳妥的方式是用memcpy，这是标准明确允许的操作，完全符合严格别名规则：

#include <cstring> // 别忘了包含memcpy的头文件

int read(const QByteArray& buffer) {
    Alias alias;
    std::memcpy(&alias, buffer.data(), sizeof(Alias));
    return static_cast<int>(alias.a);
}

至于你提到的联合体，虽然有些场景下会被用来做类型转换，但要注意：C++标准里，只有当联合体的某个成员已经被“激活构造”后，才能访问它。如果只是把char数组和Alias放进同一个联合体，先填充char数组再直接访问Alias成员，这其实也是UB（除非你用placement-new在联合体里构造Alias）。相比之下，memcpy的逻辑更清晰，也更容易保证安全性。

内容的提问来源于stack exchange，提问作者Nicolas Holthaus