允许将 T* 与字符*混叠.是否也允许反过来

由于涉及指针转换，您的某些代码存在问题。请记住，在这些情况下，reinterpret_cast<T*>(e)具有static_cast<T*>(static_cast<void*>(e))的语义，因为所涉及的类型是标准布局。(事实上，我建议您在处理存储时始终使用static_castviacv void*。

仔细阅读该标准表明，在指针与T*之间的转换过程中，假设确实涉及一个实际的对象T*- 这在您的某些代码段中很难实现，即使由于所涉及的类型的琐碎而"作弊"(稍后会详细介绍)。然而，那将不是重点，因为...

别名与指针转换无关。这是 C++11 文本，概述了通常称为"严格别名"规则的规则，来自 3.10 左值和右值 [basic.lval]：

10 如果程序尝试通过以下类型之一以外的 glvalue 访问对象的存储值，则行为未定义：

• 对象的动态类型，
• 对象的动态类型的 CV 合格版本，
• 与对象的动态类型类似(如 4.4 中所定义)的类型，
• 一种类型，该类型是对应于对象的动态类型的有符号或无符号类型，
一种类型，
• 该类型是与对象的动态类型的 CV 限定版本相对应的有符号或无符号类型，
在其元素或非静态数据成员中包含上述类型之一的聚合或联合
• 类型(递归地包括子聚合或包含的联合的元素或非静态数据成员)，
• 一种类型，该类型是对象的动态类型的基类类型(可能符合 CV 标准)，
• 字符或无符号字符类型。

(这是C++03中同一条款和子条款的第15段，对文本进行了一些细微的更改，例如使用"lvalue"而不是"glvalue"，因为后者是C++11的概念。

根据这些规则，让我们假设一个实现为我们提供了"以某种方式"将指针转换为另一种指针类型的magic_cast<T*>(p)。通常这是reinterpret_cast的，在某些情况下会产生未指定的结果，但正如我之前所解释的，对于指向标准布局类型的指针来说并非如此。那么很明显，你所有的片段都是正确的(用magic_cast替换reinterpret_cast)，因为magic_cast的结果不涉及任何glvalue。

这是一个似乎错误地使用magic_cast的片段，但我认为是正确的：

// assume constexpr max
constexpr auto alignment = max(alignof(int), alignof(short));
alignas(alignment) char c[sizeof(int)];
// I'm assuming here that the OP really meant to use &c and not c
// this is, however, inconsequential
auto p = magic_cast<int*>(&c);
*p = 42;
*magic_cast<short*>(p) = 42;

为了证明我的推理，假设这个表面上不同的片段：

// alignment same as before
alignas(alignment) char c[sizeof(int)];
auto p = magic_cast<int*>(&c);
// end lifetime of c
c.~decltype(c)();
// reuse storage to construct new int object
new (&c) int;
*p = 42;
auto q = magic_cast<short*>(p);
// end lifetime of int object
p->~decltype(0)();
// reuse storage again
new (p) short;
*q = 42;

此代码段经过精心构造。特别是，在new (&c) int;中，即使由于 3.8 对象生存期 [basic.life] 第 5 段中规定的规则c被销毁，我也可以使用&c。该段对存储的引用给出了非常相似的规则，第 7 段解释了变量、指针和引用会发生什么，这些变量、指针和引用在重新使用存储后用于引用对象——我将统称为 3.8/5-7。

在这种情况下，&c被(隐式地)转换为void*，这是指向尚未重用的存储的指针的正确用法之一。同样，在建造新int之前，从&c获得p。它的定义也许可以在c销毁之后，这取决于实施魔法的深度，但肯定不是在int构造之后：第7段将适用，这不是允许的情况之一。short对象的构造还依赖于p成为存储的指针。

现在，由于int和short是简单的类型，因此我不必使用对析构函数的显式调用。我也不需要对构造函数的显式调用(也就是说，对<new>中声明的常规标准放置新位置的调用)。从 3.8 对象生存期 [basic.life]：

1 [...]T 类型的对象的生存期在以下情况下开始：

• 获得具有T型正确对齐和大小的存储，并且
• 如果对象具有非平凡的初始化，则其初始化完成。

T 类型的对象的生存期在以下情况下结束：

• 如果 T 是具有非平凡析构函数 (12.4) 的类类型，则析构函数调用将启动，或者
• 对象占用的存储被重用或释放。

这意味着我可以重写代码，以便在折叠中间变量q后，我最终得到原始代码段。

请注意，p不能折叠起来。也就是说，以下绝对不正确：

alignas(alignment) char c[sizeof(int)];
*magic_cast<int*>(&c) = 42;
*magic_cast<short*>(&c) = 42;

如果我们假设一个int对象是用第二行(微不足道地)构造的，那么这必然意味着&c成为指向已重用的存储的指针。因此，第三行是不正确的 - 尽管由于 3.8/5-7 而不是严格意义上的混叠规则。

如果我们不假设这一点，那么第二行就违反了混叠规则：我们通过类型int的 glvalue 读取实际上是一个char c[sizeof(int)]对象，这不是允许的例外之一。相比之下，*magic_cast<unsigned char>(&c) = 42;就可以了(我们假设一个short对象是在第三行上简单构造的)。

就像 Alf 一样，我也建议您在使用存储时明确使用标准放置新。跳过琐碎类型的销毁是可以的，但是当遇到*some_magic_pointer = foo;时，您很可能会面临违反 3.8/5-7(无论该指针是如何神奇地获得)或混叠规则的。这也意味着存储新表达式的结果，因为一旦对象被构造，你很可能无法重用魔术指针 - 由于3.8/5-7再次。

但是，读取对象的字节(这意味着使用char或unsigned char)是可以的，您甚至根本不需要使用reinterpret_cast或任何魔法。 通过cv void*static_cast可以说对这项工作很好(尽管我确实觉得标准可以在那里使用更好的措辞)。

这也是：

// valid: char -> type
alignas(int) char c[sizeof(int)];
int * i = reinterpret_cast<int*>(c);

这是不正确的。别名规则规定了在哪些情况下通过不同类型的左值访问对象是合法/非法的。有一个特定的规则说您可以通过char或unsigned char类型的指针访问任何对象，因此第一种情况是正确的。也就是说，A => B 并不一定意味着 B => A。您可以通过指向char的指针访问int，但不能通过指向int的指针访问char。

为了Alf的利益：

如果程序尝试通过以下类型之一以外的 glvalue 访问对象的存储值，则行为是未定义的：

• 对象的动态类型，
• 对象的动态类型的 CV 合格版本，
• 与对象的动态类型类似(如 4.4 中所定义)的类型，
• 一种类型，该类型是对应于对象的动态类型的有符号或无符号类型，
一种类型，
• 该类型是与对象的动态类型的 CV 限定版本相对应的有符号或无符号类型，
在其元素或非静态数据成员中包含上述类型之一的聚合或联合
• 类型(递归地包括子聚合或包含的联合的元素或非静态数据成员)，
• 一种类型，该类型是对象的动态类型的基类类型(可能符合 CV 标准)，
• 字符或无符号字符类型。

关于 ...

alignas(int) char c[sizeof(int)];
int * i = reinterpret_cast<int*>(c);

reinterpret_cast本身是否正常，在生成有用指针值的意义上，具体取决于编译器。在此示例中，不使用结果，特别是不访问字符数组。因此，关于该示例，没有太多可以说的：它只是取决于。

但是，让我们考虑一个涉及别名规则的扩展版本：

void foo( char* );
alignas(int) char c[sizeof( int )];
foo( c );
int* p = reinterpret_cast<int*>( c );
cout << *p << endl;

让我们只考虑编译器保证有用的指针值的情况，该值会将 pointee 放置在相同的内存字节中(这取决于编译器的原因是 §5.2.10/7 中的标准仅保证它用于类型对齐兼容的指针转换，否则将其保留为"未指定"(但是， 整个§5.2.10与§9.2/18有些不一致)。

现在，对标准的§3.10/10的一种解释，即所谓的"严格混叠"条款(但请注意，该标准从未使用过术语"严格混叠")，

如果程序尝试通过以下类型之一以外的 glvalue 访问对象的存储值，则行为是未定义的：

• 对象的动态类型，
• 对象的动态类型的 CV 合格版本，
• 与对象的动态类型类似(如 4.4 中所定义)的类型，
• 一种类型，该类型是对应于对象的动态类型的有符号或无符号类型，
一种类型，
• 该类型是与对象的动态类型的 CV 限定版本相对应的有符号或无符号类型，
在其元素或非静态数据成员中包含上述类型之一的聚合或联合
• 类型(递归地包括子聚合或包含的联合的元素或非静态数据成员)，
• 一种类型，该类型是对象的动态类型的基类类型(可能符合 CV 标准)，
• char或unsignedchar类型。

正如它本身所说，这涉及驻留在c字节中的对象的动态类型。

通过这种解释，如果foo在那里放置了一个int对象，则对*p的读取操作是可以的，否则则不行。因此，在这种情况下，char数组是通过int*指针访问的。没有人怀疑另一种方式是有效的：即使foo可能在这些字节中放置了一个int对象，您也可以通过 §3.10/10 的最后一段破折号自由访问该对象作为char值序列。

因此，通过这种(通常的)解释，在foo在那里放置了一个int之后，我们可以将其作为char对象进行访问，因此至少有一个char对象存在于名为c的内存区域中;我们可以int访问它，所以至少那里也存在一个int;所以大卫在另一个答案中的断言char对象不能作为int访问， 与这种通常的解释不相容。

大卫的断言也与最常见的放置新用法不相容。

关于还有什么其他可能的解释，也许可以与大卫的断言相容，好吧，我想不出任何有意义的解释。

因此，总而言之，就神圣标准而言，仅仅将自己投向数组的T*指针实际上有用与否取决于编译器，而访问指向的可能值是否有效取决于存在的内容。特别是，考虑int的陷阱表示：如果位模式恰好是那样，你不会希望它炸毁你。因此，为了安全起见，您必须知道里面有什么，位，并且正如上面对foo的调用所表明的那样，编译器通常可能不知道，就像 g++ 编译器的严格基于对齐的优化器通常不知道