Question

标准是否以某种方式保证sizeof(typename aligned_storage<...>::type)是可以从其地址开始写入对齐存储的实际可用数据大小？我问这个的原因是我正在实现一个std :: function样式对象，如果对象适合一些小的aligned_storage，它会避免堆分配。

我查看了std :: function构造函数的libc ++实现（这样做），并且他们执行的测试是为了确保传递的类型适合对齐的存储只是...

if (sizeof(_FF) <= sizeof(__buf_) && is_nothrow_copy_constructible<_Fp>::value)
{
    __f_ = (__base*)&__buf_;
    ::new (__f_) _FF(_VSTD::move(__f));
}

__buf_是aligned_storage，_FF是类型擦除传递的仿函数的包装类，而_Fp是仿函数类型。

我假设这不能得到保证，并且它（可能是？）只是由于aligned_storage的libc ++实现而发生。

Answer 1

std::aligned_storage<len, align>::type是POD类型。这意味着它是普通的旧数据。

它是怎么回事无所谓。它只是普通的旧数据。

现在，它有额外的保证。它还可用于对齐要求len的大小为align的对象的对齐存储，但这些附加要求不会将其保证作为普通旧数据减少。

简单的旧数据就是它所说的：普通的旧数据。

POD类型可以复制到数组中，并从数组中复制，然后它具有“相同的状态”。这样的副本可以包含其完整大小（[basic.types] 3.9 / 2）。对特定行为有更多类似的保证。

理论上，我怀疑赋值/复制可能不会复制POD中的每个字节，但这样做是安全的。

我想你可以有一个代表某种掩码内存的类型，以便memcpy透明地忽略一些字节，并且由于该类型的值仅由某些字节保存，而其他字节不保留被忽略的字节对3.9的保证不是问题，但这既有问题，也不是我能想到的任何编译器所使用的实现。

sizeof std :: aligned_storage实际可用的存储大小？

1 个答案: