关于c ++：POD类型是否总是对齐？

例如，如果声明一个long变量，是否可以假定它始终在" sizeof(long)"边界上对齐？ Microsoft Visual C ++联机帮助说是这样，但这是标准行为吗？

一些更多的信息：

一种。 可以显式创建未对齐的整数(* bar)：

char foo[5]

int * bar = (int *)(&foo[1]);

b。 显然，＃pragma pack()仅影响结构，类和联合。

C。 MSVC文档指出POD类型与它们各自的大小对齐(但是，它始终是默认情况还是默认情况，它是标准行为，我不知道)

正如其他人提到的那样，这不是标准的一部分，而是由编译器来实现，因为它认为适合所讨论的处理器。例如，VC可以轻松实现与x86处理器不同的ARM处理器对齐要求。

Microsoft VC实现基本上称为自然对齐的方法，直到#pragma pack指令或/ Zp命令行选项指定的大小为止。这意味着，例如，任何大小小于或等于8个字节的POD类型都将根据其大小对齐。较大的将在8字节边界上对齐。

如果控制不同处理器和不同编译器的对齐很重要，那么可以使用1的打包大小并填充结构。

在此代码中，padding1变量仅用于确保data2自然对齐。

答案：

是的，这很容易导致数据未对齐。在x86处理器上，这实际上并没有多大伤害。在其他处理器上，这可能导致崩溃或执行速度非常慢。例如，Alpha处理器将抛出处理器异常，该异常将被OS捕获。然后，操作系统将检查指令，然后进行处理未对齐数据所需的工作。然后执行继续。可以在VC中使用__unaligned关键字来标记非x86程序(即，对于CE)的未对齐访问。

默认情况下，是。但是，可以通过pack()#pragma进行更改。

我不认为C ++标准在这方面有任何要求，而将其留待实施。

C和C ++不要求任何对齐方式。但是x86强烈建议采用自然对齐方式，大多数其他CPU体系结构都要求采用自然对齐方式，并且编译器通常会尽最大努力使CPU满意。因此，在实践中，除非您真的扭曲了编译器，否则您不会看到编译器生成未对齐的数据。

通常，这是因为对它的读/写速度更快。但是几乎每个编译器都有一个开关来关闭它。在gcc中，它是-malign-???。对于聚集体，它们通常根据其中每个元素的对齐要求进行对齐和调整大小。

取决于编译器，编译指示和优化级别。使用现代编译器，您还可以选择时间或空间优化，这也可以改变类型的对齐方式。

是的，所有类型都始终至少符合其对齐要求。

怎么会这样呢？

但请注意，类型的sizeof()与对齐方式不同。

您可以使用以下宏来确定类型的对齐要求：