为什么支持在 std::aligned_storage_t 中定义扩展对齐实现？指定一个在内部适当大小的缓冲区上使用 alignas() 的实现应该很容易吗？
最佳答案
所有对扩展对齐的支持都是implementation defined :
It is implementation-defined whether any extended alignments are supported and the contexts in which they are supported.
添加了强调。
实现可以在某些地方自由支持扩展对齐，而在其他地方不支持。创建具有扩展对齐的堆对象可能没问题，但不能创建堆栈对象(或作为堆栈变量的子对象)。 aligned_storage 只是另一个上下文。
why [extended alignment] is implementation defined in some contexts where it should be well-defined (such as stack memory)?
考虑堆分配与堆栈分配的实现负担。
对于堆分配，编译器需要做什么才能使 new OverAlignedType 工作？ C++17 之前的版本？它什么都不需要。 ::operator new 将恰好分配适合该对齐或未定义行为结果的存储。编译器对此有零控制。 placement-new 也是如此；在这种情况下，由用户正确对齐。
C++17 添加了 operator new 的对齐形式。但即便如此，唯一的区别是调用了哪个版本的函数。对于编译器来说，这很容易实现。
现在考虑堆栈分配。我创建了一个 OverAlignedType 类型的变量。好的，那如何实现呢？显然，编译器会根据堆栈上的先前分配查看函数中该点的堆栈偏移量。然后——
错了! 为什么？因为该函数调用中堆栈开始 的实际地址的对齐方式可能不适合该类型。请记住:对于任何给定的函数调用，堆栈地址将基于当前调用图是什么。如果你的 OverAlignedType 需要 32 字节对齐，而 ABI 只需要 16 字节对齐堆栈的开头，那么很可能有时，用户恰好在堆栈将要调用时调用它处于 32 字节边界，有时仅为 16 字节。
那你是做什么的？好吧，您必须执行一些运行时代码 才能查看实际堆栈地址并将其对齐到需要的位置。请注意，这会将静态的编译时偏移量变成动态偏移量。这也可能会影响该函数中每个堆栈对象的放置。
或者您可以禁止用户在堆栈上使用过度对齐的类型。
关于c++ - 为什么在 std::aligned_storage 中定义扩展对齐实现，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56420657/