Windows 为什么x64项目使用默认的打包对齐方式16？

如果在VS2012中的x64项目中编译以下代码，而不使用任何/Zp标志：

#pragma pack(show)

然后编译器将吐出：

value of pragma pack(show) == 16

value of pragma pack(show) == 8

如果项目使用Win32，则编译器将输出：

value of pragma pack(show) == 16

value of pragma pack(show) == 8

我不明白的是，在Win64中，任何类型（即：long和pointer）的最大自然对齐是8。那么，为什么不为x64设置默认对齐方式8呢

与此有些关联，为什么会有人使用/Zp16

编辑：

这里有一个例子来说明我所说的。即使x64的指针具有8字节的自然对齐方式，Zp1也可以将它们强制为1字节边界

struct A
{
    char a;
    char* b;
}

// Zp16
// Offset of a == 0
// Offset of b == 8

// Zp1
// Offset of a == 0
// Offset of b == 1

现在，如果我们举一个使用SSE的例子：

struct A
{
    char a;
    char* b;
    __m128 c; // uses declspec(align(16)) in xmmintrinsic.h
}

// Zp16
// Offset of a == 0
// Offset of b == 8
// Offset of c == 16

// Zp1
// Offset of a == 0
// Offset of b == 1
// Offset of c == 16

如果m128是真正的内置类型，那么我希望Zp1的偏移量为9。但由于它在xmmintrinsic.h中的定义中使用了uu declspec（align（16）），因此它胜过任何Zp设置

因此，我的问题的措辞有些不同：“c”是否有一种类型具有16B的自然对齐，但在上一个示例中偏移量为9？

包括以下有关您的问题的相关信息：“为什么不为x64设置默认对齐8？”：

编写使用最新处理器指令的应用程序会引入一些新的约束和问题。特别是，许多新指令要求数据必须与16字节边界对齐。此外，通过将常用数据与特定处理器的缓存线大小对齐，可以提高缓存性能。例如，如果定义的结构的大小小于32字节，则可能希望将其与32字节对齐，以确保高效缓存该结构类型的对象

为什么x64项目使用默认的打包对齐方式16

---

在x64上，浮点在SSE单元中执行。您可以声明最大的类型具有对齐8。但这是不对的。例如，一些SSE内在类型的对齐度为16。

Fair point，我真的不是低级别的专家，只是太多了，无法在评论中发表。我想这可能会提供一些信息，但我知道这不是一个答案，对不起。这个答案是正确的。64位代码生成器喜欢使用SSE2指令。它们有16字节的对齐要求。特别是在VS2012中，它增加了自动矢量化。这个答案不应该被否决。@HansPassant，我用一个例子编辑了这个问题。顺便说一句，我对答案投了反对票，因为他承认不知道自己在说什么。我也觉得它含糊不清。话虽如此，您的答案更接近我的预期……通过_declspec（align（16））__declspec（align）覆盖Zp和“#pragma pack”。由于它使用uu declspec（align），您不能像使用指针或int或其他任何东西那样通过/Zp更改其对齐方式。此外，由于它使用u declspec（align（16）），因此默认的16字节对齐方式没有意义。它可以是8个字节，但declspec仍然会强制它为16。我回答了这个问题。我引用了问题中的一句话来说明我在回答什么。你回答了一个问题，但不是我的。哦，我以为问题的标题是你写的。