我遇到了一个情况，我必须使用std::unique_ptr<bool[]>，它位于HDF5库(用于高效二进制数据存储的库，在科学中使用很多)中。一些编译器(在我的例子中是Visual Studio 2015)提供std::vector<bool>的压缩(通过在每个字节中使用8个bool)，这对于HDF5之类的东西来说是一个灾难，它不关心这种压缩。对于std::vector<bool>， HDF5最终会因为压缩而读取垃圾。

猜猜谁在那里进行救援，在std::vector不起作用的情况下，我需要干净地分配一个动态数组?: -)

如果您需要一个不可复制构造的对象的动态数组，那么可以使用一个指向数组的智能指针。例如，如果您需要一个原子数组怎么办?

Scott Meyers在《Effective Modern c++》中这样说

对于数组来说，是否存在std::unique_ptr应该只对你的智力感兴趣，因为std::array， Std::vector, Std::string实际上总是比原始数组更好的数据结构选择。关于我能想到的唯一情况，当std::unique_ptr<T[]>有意义时，当你使用一个类似c的API，返回一个原始指针指向你假定拥有的堆数组时。

我认为Charles Salvia的答案是相关的:std::unique_ptr<T[]>是初始化一个在编译时不知道大小的空数组的唯一方法。对于使用std::unique_ptr<T[]>的动机，Scott Meyers会说些什么呢?

这里有权衡，您可以选择与您想要的匹配的解决方案。我能想到的是:

初始大小

vector和unique_ptr<T[]>允许在运行时指定大小 数组只允许在编译时指定大小

调整

array和unique_ptr<T[]>不允许调整大小 向量是

存储

vector和unique_ptr<T[]>将数据存储在对象之外(通常在堆上) 数组将数据直接存储在对象中

复制

数组和向量允许复制 unique_ptr<T[]>不允许复制

交换/移动

vector和unique_ptr<T[]>有O(1)次交换和移动操作 数组有O(n)次交换和移动操作，其中n是数组中元素的数量

指针/引用/迭代器失效

array ensures pointers, references and iterators will never be invalidated while the object is live, even on swap() unique_ptr<T[]> has no iterators; pointers and references are only invalidated by swap() while the object is live. (After swapping, pointers point into to the array that you swapped with, so they're still "valid" in that sense.) vector may invalidate pointers, references and iterators on any reallocation (and provides some guarantees that reallocation can only happen on certain operations).

概念和算法的兼容性

array和vector都是容器 unique_ptr<T[]>不是容器

我不得不承认，对于基于策略的设计来说，这似乎是一个重构的机会。

出于二进制兼容性的考虑，您需要结构只包含一个指针。 你需要使用一个API来返回用new[]分配的内存 例如，您的公司或项目有一个禁止使用std::vector的一般规则，以防止粗心的程序员不小心引入副本 您希望防止粗心的程序员在这种情况下意外地引入副本。

有一个普遍的规则，c++容器比使用指针滚动自己的容器更受欢迎。这是一个普遍规律;它有例外。有更多的;这些只是例子。

I have used unique_ptr<char[]> to implement a preallocated memory pools used in a game engine. The idea is to provide preallocated memory pools used instead of dynamic allocations for returning collision requests results and other stuff like particle physics without having to allocate / free memory at each frame. It's pretty convenient for this kind of scenarios where you need memory pools to allocate objects with limited life time (typically one, 2 or 3 frames) that do not require destruction logic (only memory deallocation).