我认为 POD（c++11，琐碎 + 标准布局）的全部意义在于确保类型与 C 兼容。
给定以下代码：
// that one is a standard layout, and trivial which makes it a c++11 POD
struct Bar
{
public:
int x;
public:
int y;
};
AFAIU，编译器可能会重新排序 x 和 y。这不会破坏与 C 的兼容性吗？
为什么在 c++11 中放宽 98/03 POD 定义被认为是个好主意？
【问题讨论】：
AFAIU，编译器可能会重新排序 x 和 y。这不会破坏与 C 的兼容性吗？
在 C++03 中，它可以。在 C++11 中它不能。 C++11 的标准布局规则仅要求所有成员具有相同的访问控制。它们不必在同一个访问控制区域中声明。
为什么在 c++11 中放宽 98/03 POD 定义被认为是个好主意？
我认为你误解了一些事情。 C++11 规则允许 more 类型是标准布局（因此可能与 C 类型布局兼容），而不是更少。因此，放宽规则并没有真正的缺点。
【讨论】：
POD 的重点不仅仅是确保类型与 C 兼容 - 请注意，具有访问说明符（public、private 等）的类型在定义上与 C 不兼容，因为 C 不'没有访问说明符。 POD 类型的主要属性是它可以被 memcpy'ed 左右。
在 C++ 类型中拥有多个访问说明符确实允许编译器以未指定的方式布局类型，这在一段时间内一直是正确的（这在 C++11 中并不新鲜）：
来自 C++03 9.2/12
声明的（非联合）类的非静态数据成员没有 分配了中间的访问说明符，以便后面的成员拥有 类对象中的更高地址。分配顺序 由访问说明符分隔的非静态数据成员未指定 (11.1)。
然而，这并没有使一个类型成为非 POD - 它仍然可以是一个 POD，只是不能用 C 语言表达。
【讨论】：
我认为 POD（c++11，琐碎 + 标准布局）的全部意义在于确保类型与 C 兼容。
不完全是它的全部意义，但是是的，这是 POD 的属性之一。
// that one is a standard layout, and trivial which makes it a c++11 POD
正确。
AFAIU，编译器可能会重新排序 x 和 y。这不会破坏与 C 的兼容性吗？
我们已经确定它是一个 POD，这意味着编译器将保持与 C 的兼容性。保持与 C 的兼容性不会破坏与 C 的兼容性。
为什么在 c++11 中放宽 98/03 POD 定义被认为是一个好主意？
因为它不会破坏任何东西。
【讨论】：