从技术上讲，在c++中，严格的混叠规则可能永远都不适用。

注意indirection(*运算符)的定义:

一元*运算符执行间接操作:它所对应的表达式 是指向对象类型的指针，还是指向对象类型的指针 函数类型，结果是指向对象或的左值 表达式所指向的函数。

同样来自glvalue的定义

glvalue是一个表达式，其求值决定的标识 一个对象，(…剪)

因此，在任何定义良好的程序跟踪中，glvalue都指向对象。所以所谓的严格混叠规则并不适用。这可能不是设计师想要的。

严格的混叠不只是指指针，它也影响引用，我为boost开发者wiki写了一篇关于它的论文，它很受欢迎，我把它变成了我的咨询网站上的一个页面。它完全解释了它是什么，为什么它让人们如此困惑，以及如何应对它。严格的混叠白皮书。它特别解释了为什么联合对于c++来说是危险的行为，以及为什么使用memcpy是唯一可以在C和c++之间移植的修复程序。希望这对你有帮助。

这是严格的混叠规则，可以在c++ 03标准的3.10节中找到(其他答案提供了很好的解释，但没有一个提供了规则本身):

If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined: the dynamic type of the object, a cv-qualified version of the dynamic type of the object, a type that is the signed or unsigned type corresponding to the dynamic type of the object, a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object, an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), a type that is a (possibly cv-qualified) base class type of the dynamic type of the object, a char or unsigned char type.

c++ 11和c++ 14的措辞(强调更改):

If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined: the dynamic type of the object, a cv-qualified version of the dynamic type of the object, a type similar (as defined in 4.4) to the dynamic type of the object, a type that is the signed or unsigned type corresponding to the dynamic type of the object, a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object, an aggregate or union type that includes one of the aforementioned types among its elements or non-static data members (including, recursively, an element or non-static data member of a subaggregate or contained union), a type that is a (possibly cv-qualified) base class type of the dynamic type of the object, a char or unsigned char type.

有两个变化很小:glvalue代替了lvalue，并澄清了聚合/并集的情况。

第三个变化提供了更强的保证(放宽强混叠规则):类似类型的新概念现在可以安全地进行混叠。

还有C的措辞(C99;Iso / iec 9899:1999 6.5/7;在ISO/IEC 9899:2011§6.5¶7中使用了完全相同的措辞:

An object shall have its stored value accessed only by an lvalue expression that has one of the following types 73) or 88): a type compatible with the effective type of the object, a qualified version of a type compatible with the effective type of the object, a type that is the signed or unsigned type corresponding to the effective type of the object, a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object, an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or a character type. 73) or 88) The intent of this list is to specify those circumstances in which an object may or may not be aliased.

从技术上讲，在c++中，严格的混叠规则可能永远都不适用。

注意indirection(*运算符)的定义:

一元*运算符执行间接操作:它所对应的表达式 是指向对象类型的指针，还是指向对象类型的指针 函数类型，结果是指向对象或的左值 表达式所指向的函数。

同样来自glvalue的定义

glvalue是一个表达式，其求值决定的标识 一个对象，(…剪)

因此，在任何定义良好的程序跟踪中，glvalue都指向对象。所以所谓的严格混叠规则并不适用。这可能不是设计师想要的。

我找到的最好的解释是Mike Acton的《Understanding Strict Aliasing》。本文主要关注PS3的开发，但这基本上只是GCC的工作。

摘自文章:

严格混叠是C(或c++)编译器的一个假设，即指向不同类型对象的指针的解引用永远不会指向相同的内存位置(即相互混叠)。

所以基本上，如果你有一个int*指向一些包含int型的内存，然后你把一个float*指向那个内存，并把它用作浮点数，你就违反了规则。如果你的代码不尊重这一点，那么编译器的优化器很可能会破坏你的代码。

该规则的例外是一个char*，它被允许指向任何类型。

作为Doug T.已经写过的附录，在这里 是一个简单的测试用例，可能会触发GCC:

check.c

#include <stdio.h>

void check(short *h,long *k)
{
    *h=5;
    *k=6;
    if (*h == 5)
        printf("strict aliasing problem\n");
}

int main(void)
{
    long      k[1];
    check((short *)k,k);
    return 0;
}

编译gcc -O2 -o check check.c。 通常(我尝试过的大多数gcc版本)这会输出“严格的混叠问题”，因为编译器假设“h”不能与“check”函数中的“k”地址相同。因此，编译器会优化if (*h == 5)，并始终调用printf。

对于那些感兴趣的人，这里有x64汇编代码，由gcc 4.6.3生成，运行在ubuntu 12.04.2的x64上:

movw    $5, (%rdi)
movq    $6, (%rsi)
movl    $.LC0, %edi
jmp puts

所以if条件从汇编代码中完全消失了。