我写了一个简单的例子：
#include <iostream>
int main() {
void* byte1 = ::operator new(1);
void* byte2 = ::operator new(1);
void* byte3 = malloc(1);
std::cout << "byte1: " << byte1 << std::endl;
std::cout << "byte2: " << byte2 << std::endl;
std::cout << "byte3: " << byte3 << std::endl;
return 0;
}
运行代码后，我得到了以下结果：
byte1: 0x1f53e70
byte2: 0x1f53e90
byte3: 0x1f53eb0
每次我分配一个单字节的内存时，它总是以16字节对齐。这是为什么呢？
我在GCC 5.4.0和GCC 7.4.0上测试了这段代码，并得到了相同的结果。
__STDCPP_DEFAULT_NEW_ALIGNMENT__ 是16，这与我在使用C++17的gcc 7.4中的测试结果一致。但是我发现，在使用C++11的gcc 5.4和C++17的gcc 7.4中，sizeof(std::max_align_t) 的值为32。 - jingeoperator new 的重载返回一个适当对齐的指针，以满足给定大小的任何完整对象类型，前提是它没有 new-extended 对齐方式，其中 new-extended 意味着大于 __STDCPP_DEFAULT_NEW_ALIGNMENT__。我没有找到任何要求这个对齐方式至少与最大的 基本对齐方式 一样大的内容，而最大的 基本对齐方式 是 alignof(std::max_align_t)（我认为您混淆了 sizeof 和 alignof）。 - walnutoperator new 的重载必须返回一个适合于任何具有基本对齐的对象的指针，但如果我理解正确的话，自 C++17 以来，可能会存在介于对齐的情况，这时就需要通过使用 operator new(std::size_t, std::align_val_t) 重载来处理。 - walnutalignof（std :: max_align_t）而不是sizeof（std :: max_align_t），您将获得与__STDCPP_DEFAULT_NEW_ALIGNMENT__相同的结果。如我在上面的评论中提到的那样，这可能是eerorika的错误，但是正如我也提到的，我认为这两个值不需要按特定方式排序（虽然我不能确定）。 - walnutmalloc() 指定对齐方式。根本没有参数。因此，malloc() 必须实现为提供在平台上任何目的下正确对齐的指针。C++ 中的 ::operator new() 遵循相同的原则。malloc() 请求一个字节时，它通常需要为至少两个额外的指针分配空间以进行自己的簿记（确切的数量取决于实现）。在 64 位架构上，这是 16 字节。因此，malloc() 不应该考虑字节，而是更有效地考虑 16 字节块。至少如此。您可以通过示例代码看到这一点：生成的指针实际上相距 32 字节。每个内存块占用 16 字节的有效载荷 + 16 字节的内部簿记内存。这取决于操作系统/CPU的要求。在32位版本的linux/win32中，分配的内存总是按8字节对齐的。在64位版本的linux/win32 中，由于所有64位CPU至少都有SSE2，所以在当时将所有内存对齐到16字节是有意义的（因为使用未对齐内存时，使用SSE2的效率较低）。随着最新的基于AVX的CPU，未对齐内存的性能惩罚已被消除，因此它们可以在任何边界上进行分配。
如果你这样考虑，将用于内存分配的地址对齐到16字节会给指针地址留下4位空间。这可能在内部存储一些附加标志（例如可读、可写、可执行等）方面很有用。
归根结底，推理完全受到操作系统和/或硬件要求的支配。这与语言无关。
movups变得便宜，但AVX允许将负载折叠到内存源操作数中，因为VEX编码版本不需要对齐。） - Peter Cordesalignof(max_align_t) = 16）。 - Peter Cordes
alignas是针对特定变量或类型使用的。我如何将默认的alignas设置为每个对象？ - jingealignas，我不知道@MosheRabaev在评论中想表达什么意思。 - walnut