blocks|key|94971|text|您可能使用unique_ptr的一个原因是，如果您不想支付value-initializing数组的运行时成本。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|94972|std::vector<char>+vec(1000000);+//+allocates+AND+value-initializes+1000000+chars

std::unique_ptr<char[]>+p(new+char[1000000]);+//+allocates+storage+for+1000000+chars|code-block|syntax|javascript|94973|std::vector构造函数和std::vector::resize()将对T进行赋值初始化--但是如果T是一个POD，new就不会这样做。|94974|请参阅Value-Initialized+Objects+in+C%2B%2B11+and+std::vector+constructor|94975|注意，在这里vector::reserve不是可选的：Is+accessing+the+raw+pointer+after+std::vector::reserve+safe?|94976|这也是C程序员可能会选择malloc而不是calloc的原因。|94977|entityMap|0|LINK|mutability|MUTABLE|url|http://en.cppreference.com/w/cpp/language/value_initialization|1|https://stackoverflow.com/questions/15097783/value-initialized-objects-in-c11-and-stdvector-constructor|2|https://stackoverflow.com/questions/8228072/is-accessing-the-raw-pointer-after-stdvectorreserve-safe^0|5|A|T|I|0|0|0|0|B|G|L|13|1|1H|1|1P|3|0|3|1Q|1|0|6|F|R|1P|2|0|C|6|L|6|0^^$0|@$1|2|3|4|5|6|7|14|8|@$9|15|A|16|B|C]]|D|@$9|17|A|18|1|19]]|E|$]]|$1|F|3|G|5|H|7|1A|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|1B|8|@$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]|$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|M|3|N|5|6|7|1M|8|@]|D|@$9|1N|A|1O|1|1P]]|E|$]]|$1|O|3|P|5|6|7|1Q|8|@$9|1R|A|1S|B|C]]|D|@$9|1T|A|1U|1|1V]]|E|$]]|$1|Q|3|R|5|6|7|1W|8|@$9|1X|A|1Y|B|C]|$9|1Z|A|20|B|C]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|21|8|@]|D|@]|E|$]]]|T|$U|$5|V|W|X|E|$Y|Z]]|10|$5|V|W|X|E|$Y|11]]|12|$5|V|W|X|E|$Y|13]]]]

One reason you might use a <code>unique_ptr</code> is if you don't want to pay the runtime cost of <a href="http://en.cppreference.com/w/cpp/language/value_initialization" rel="noreferrer">value-initializing</a> the array.

<pre><code>std::vector&lt;char&gt; vec(1000000); // allocates AND value-initializes 1000000 chars

std::unique_ptr&lt;char[]&gt; p(new char[1000000]); // allocates storage for 1000000 chars
</code></pre>

The <code>std::vector</code> constructor and <code>std::vector::resize()</code> will value-initialize <code>T</code> - but <code>new</code> will not do that if <code>T</code> is a POD.

See <a href="https://stackoverflow.com/questions/15097783/value-initialized-objects-in-c11-and-stdvector-constructor">Value-Initialized Objects in C++11 and std::vector constructor</a>

Note that <code>vector::reserve</code> is not an alternative here: <a href="https://stackoverflow.com/questions/8228072/is-accessing-the-raw-pointer-after-stdvectorreserve-safe">Is accessing the raw pointer after std::vector::reserve safe?</a>

It's the same reason a C programmer might choose <code>malloc</code> over <code>calloc</code>.

blocks|key|311785|text|std::vector可以被复制，而unique_ptr<int[]>允许表示对数组的唯一所有权。另一方面，std::array要求在编译时确定大小，这在某些情况下可能是不可能的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|311786|entityMap^0|0|B|I|H|1I|A|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

An <code>std::vector</code> can be copied around, while <code>unique_ptr&lt;int[]&gt;</code> allows expressing unique ownership of the array. <code>std::array</code>, on the other hand, requires the size to be determined at compile-time, which may be impossible in some situations.

blocks|key|95005|text|与std::vector和std::array相反，std::unique_ptr可以拥有空指针。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|95006|当使用需要数组或NULL的C+API时，这很方便：|95007|void+legacy_func(const+int+*array_or_null);

void+some_func()+{++++
++++std::unique_ptr<int[]>+ptr;
++++if+(some_condition)+{
++++++++ptr.reset(new+int[10]);
++++}

++++legacy_func(ptr.get());
}|code-block|syntax|javascript|95008|entityMap^0|1|B|D|A|Q|F|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|W|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|X|8|@]|D|@]|E|$]]]|N|$]]

Contrary to <code>std::vector</code> and <code>std::array</code>, <code>std::unique_ptr</code> can own a NULL pointer. 
This comes in handy when working with C APIs that expect either an array or NULL:

<pre><code>void legacy_func(const int *array_or_null);

void some_func() { 
 std::unique_ptr&lt;int[]&gt; ptr;
 if (some_condition) {
 ptr.reset(new int[10]);
 }

 legacy_func(ptr.get());
}
</code></pre>

blocks|key|95036|text|简而言之:它是目前为止内存效率最高的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|95037|std::string带有一个指针、一个长度和一个“短串优化”缓冲区。但我的情况是，我需要存储一个几乎总是空的字符串，在一个我有数十万个的结构中。在C语言中，我只会使用char+*，而且大部分时间都是空的。这也适用于C%2B%2B，只是char+*没有析构函数，并且不知道如何删除自身。相比之下，当std::unique_ptr<char[]>超出作用域时，它会自动删除。一个空的std::string占用32个字节，但是一个空的std::unique_ptr<char[]>占用8个字节，也就是说，它的指针大小正好一样。|offset|length|style|CODE|95038|最大的缺点是，每次我想知道字符串的长度时，我都必须对它调用strlen。|95039|entityMap^0|0|0|B|2C|6|36|6|41|N|56|B|5V|N|0|T|6|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]|$D|R|E|S|F|G]|$D|T|E|U|F|G]|$D|V|E|W|F|G]|$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@$D|10|E|11|F|G]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|K|$]]

In a nutshell: it's by far the most memory-efficient.

A <code>std::string</code> comes with a pointer, a length, and a "short-string-optimization" buffer. But my situation is I need to store a string that is almost always empty, in a structure that I have hundreds of thousands of. In C, I would just use <code>char *</code>, and it would be null most of the time. Which works for C++, too, except that a <code>char *</code> has no destructor, and doesn't know to delete itself. By contrast, a <code>std::unique_ptr&lt;char[]&gt;</code> will delete itself when it goes out of scope. An empty <code>std::string</code> takes up 32 bytes, but an empty <code>std::unique_ptr&lt;char[]&gt;</code> takes up 8 bytes, that is, exactly the size of its pointer.

The biggest downside is, every time I want to know the length of the string, I have to call <code>strlen</code> on it.

blocks|key|94881|text|我已经使用unique_ptr<char[]>实现了游戏引擎中使用的预分配内存池。这个想法是提供预先分配的内存池，而不是动态分配，用于返回碰撞请求、结果和其他类似粒子物理的东西，而不必在每一帧分配/释放内存。对于这种场景，你需要内存池来分配生命周期有限的对象(通常是一帧、两帧或三帧)，而这些对象不需要销毁逻辑(只需要内存释放)，这是非常方便的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|94882|entityMap^0|5|I|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

I have used <code>unique_ptr&lt;char[]&gt;</code> 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).

blocks|key|95235|text|我完全不同意这个被接受的答案的精神。“最后的工具”？差得远呢!|type|unstyled|depth|inlineStyleRanges|entityRanges|data|95236|在我看来，与C和其他一些类似的语言相比，C%2B%2B最强大的功能之一是能够表达约束，以便在编译时可以检查它们，并可以防止意外的误用。因此，当设计一个结构时，问问你自己它应该允许什么操作。所有其他的使用都应该被禁止，最好是这样的限制可以静态地实现(在编译时)，这样误用就会导致编译失败。|95237|因此，当一个人需要一个数组时，对以下问题的回答指定了它的行为:+1.它的大小是a)运行时动态的，还是b)静态的，但仅在运行时知道的，还是c)静态的并在编译时已知的?+2.该数组是否可以分配到堆栈上？|95238|根据答案，这是我认为这样的数组最好的数据结构：|95239|+++++++Dynamic+++++%7C+++Runtime+static+++%7C+++++++++Static
Stack+std::vector++++++unique_ptr<T[]>++++++++++std::array
Heap++std::vector++++++unique_ptr<T[]>+++++unique_ptr<std::array>|code-block|syntax|javascript|95240|是的，我认为unique_ptr<std::array>也应该被考虑，而且两者都不是最后的工具。只要想一想什么最适合你的算法。|offset|length|style|CODE|95241|所有这些都通过指向数据数组的原始指针(vector.data()+/+array.data()+/+uniquePtr.get())与纯C+API兼容。|95242|除了上述考虑之外，还有一个所有权问题：std::array和std::vector具有值语义(对复制和按值传递具有本机支持)，而unique_ptr<T[]>只能移动(强制单一所有权)。这两种方法在不同的场景中都很有用。相反，普通静态数组(int[N])和普通动态数组(new+int[10])两者都不提供，因此应该尽可能避免-这在绝大多数情况下都应该是可能的。如果这还不够，普通的动态数组也没有办法查询它们的大小--这是内存损坏和安全漏洞的额外机会。|95243|entityMap^0|0|0|0|0|0|6|M|0|J|D|Z|C|1E|F|0|J|A|U|B|1S|F|3C|6|3R|B|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|12|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|13|8|@$O|14|P|15|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|16|8|@$O|17|P|18|Q|R]|$O|19|P|1A|Q|R]|$O|1B|P|1C|Q|R]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1D|8|@$O|1E|P|1F|Q|R]|$O|1G|P|1H|Q|R]|$O|1I|P|1J|Q|R]|$O|1K|P|1L|Q|R]|$O|1M|P|1N|Q|R]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]]|X|$]]

I can't disagree with the spirit of the accepted answer strongly enough. "A tool of last resort"? Far from it!

The way I see it, one of the strongest features of C++ compared to C and to some other similar languages is the ability to express constraints so that they can be checked at compile time and accidental misuse can be prevented. So when designing a structure, ask yourself what operations it should permit. All the other uses should be forbidden, and it's best if such restrictions can be implemented statically (at compile time) so that misuse results in a compilation failure.

So when one needs an array, the answers to the following questions specify its behavior:
1. Is its size a) dynamic at runtime, or b) static, but only known at runtime, or c) static and known at compile time?
2. Can the array be allocated on the stack or not?

And based on the answers, this is what I see as the best data structure for such an array:

<pre><code> Dynamic | Runtime static | Static
Stack std::vector unique_ptr&lt;T[]&gt; std::array
Heap std::vector unique_ptr&lt;T[]&gt; unique_ptr&lt;std::array&gt;
</code></pre>

Yep, I think <code>unique_ptr&lt;std::array&gt;</code> should also be considered, and neither is a tool of last resort. Just think what fits best with your algorithm.

All of these are compatible with plain C APIs via the raw pointer to data array (<code>vector.data()</code> / <code>array.data()</code> / <code>uniquePtr.get()</code>).

P. S. Apart from the above considerations, there's also one of ownership: <code>std::array</code> and <code>std::vector</code> have value semantics (have native support for copying and passing by value), while <code>unique_ptr&lt;T[]&gt;</code> can only be moved (enforces single ownership). Either can be useful in different scenarios. On the contrary, plain static arrays (<code>int[N]</code>) and plain dynamic arrays (<code>new int[10]</code>) offer neither and thus should be avoided if possible - which should be possible in the vast majority of cases. If that wasn't enough, plain dynamic arrays also offer no way to query their size - extra opportunity for memory corruptions and security holes.

blocks|key|95126|text|我遇到了一个案例，我不得不使用HDF5库中的std::unique_ptr<bool[]>+(一个用于有效存储二进制数据的库，在科学中使用得很多)。一些编译器(在我的例子中是Visual+Studio2015)+provide+compression+of+std::vector+(通过在每个字节中使用8个bool)，这对于HDF5这样的东西来说是一个灾难，它并不关心这种压缩。在std::vector<bool>中，由于这种压缩，HDF5最终读取了垃圾。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|95127|猜猜在std::vector不能工作的情况下，谁来拯救我，我需要干净利落地分配一个动态数组？:-)|95128|entityMap|0|LINK|mutability|MUTABLE|url|http://en.cppreference.com/w/cpp/container/vector_bool^0|M|N|3L|B|5B|H|2Y|Y|0|0|3|B|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@$9|W|A|X|1|Y]]|E|$]]|$1|F|3|G|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

I faced a case where I had to use <code>std::unique_ptr&lt;bool[]&gt;</code>, which was in the HDF5 library (A library for efficient binary data storage, used a lot in science). Some compilers (Visual Studio 2015 in my case) <a href="http://en.cppreference.com/w/cpp/container/vector_bool" rel="noreferrer">provide compression of <code>std::vector&lt;bool&gt;</code></a> (by using 8 bools in every byte), which is a catastrophe for something like HDF5, which doesn't care about that compression. With <code>std::vector&lt;bool&gt;</code>, HDF5 was eventually reading garbage because of that compression.

Guess who was there for the rescue, in a case where <code>std::vector</code> didn't work, and I needed to allocate a dynamic array cleanly? :-)

blocks|key|95188|text|为了回答人们认为你“必须”使用vector而不是unique_ptr的想法，我有一个在GPU上进行CUDA编程的例子，当你在设备中分配内存时，你必须使用指针数组(使用cudaMalloc)。然后，当在主机中检索此数据时，您必须再次获取指针，unique_ptr可以很容易地处理指针。将double*转换为vector<double>的额外成本是不必要的，并且会导致性能损失。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|95189|entityMap^0|F|6|O|A|2B|A|3C|A|3Y|7|48|E|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|U|8|@]|D|@]|E|$]]]|G|$]]

To answer people thinking you "have to" use <code>vector</code> instead of <code>unique_ptr</code> I have a case in CUDA programming on GPU when you allocate memory in Device you must go for a pointer array (with <code>cudaMalloc</code>).
Then, when retrieving this data in Host, you must go again for a pointer and <code>unique_ptr</code> is fine to handle pointer easily.
The extra cost of converting <code>double*</code> to <code>vector&lt;double&gt;</code> is unnecessary and leads to a loss of perf.

blocks|key|311876|text|当您只能通过现有的API+(想想窗口消息或与线程相关的回调参数)戳到一个指针时，它们可能是最正确的答案，这些API在被“捕获”到阴影的另一边后具有一定的生存期，但这与调用代码无关：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|311877|unique_ptr<byte[]>+data+=+get_some_data();

threadpool->post_work([](void*+param)+{+do_a_thing(unique_ptr<byte[]>((byte*)param));+},
++++++++++++++++++++++data.release());|code-block|syntax|javascript|311878|我们都希望事情对我们有利。C%2B%2B是用于其他时间的。|311879|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

They may be the rightest answer possible when you only get to poke a single pointer through an existing API (think window message or threading-related callback parameters) that have some measure of lifetime after being "caught" on the other side of the hatch, but which is unrelated to the calling code:

<pre><code>unique_ptr&lt;byte[]&gt; data = get_some_data();

threadpool-&gt;post_work([](void* param) { do_a_thing(unique_ptr&lt;byte[]&gt;((byte*)param)); },
 data.release());
</code></pre>

We all want things to be nice for us. C++ is for the other times.

blocks|key|312015|text|您可以在需要C语言的性能和C%2B%2B的便利性的地方使用unique_ptr<char[]>。考虑你需要对数百万(好吧，如果你还不信任的话，数十亿)字符串进行操作。对于内存(堆)管理例程来说，将它们分别存储在单独的string或vector<char>对象中将是一场灾难。尤其是当你需要多次分配和删除不同的字符串时。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|312016|但是，您可以分配单个缓冲区来存储如此多的字符串。你不喜欢char*+buffer+=+(char*)malloc(total_size);的原因很明显(如果不是很明显，搜索“为什么使用智能ptrs")。你更喜欢unique_ptr<char[]>+buffer(new+char[total_size]);|312017|以此类推，同样的性能和便利性考虑因素也适用于非char数据(考虑数百万个向量/矩阵/对象)。|312018|entityMap^0|P|I|2W|6|33|C|0|S|15|2X|1C|0|N|4|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|K|$]]

<code>unique_ptr&lt;char[]&gt;</code> can be used where you want the performance of C and convenience of C++. Consider you need to operate on millions (ok, billions if you don't trust yet) of strings. Storing each of them in a separate <code>string</code> or <code>vector&lt;char&gt;</code> object would be a disaster for the memory (heap) management routines. Especially if you need to allocate and delete different strings many times.

However, you can allocate a single buffer for storing that many strings. You wouldn't like <code>char* buffer = (char*)malloc(total_size);</code> for obvious reasons (if not obvious, search for "why use smart ptrs"). You would rather like <code>unique_ptr&lt;char[]&gt; buffer(new char[total_size]);</code>

By analogy, the same performance&amp;convenience considerations apply to non-<code>char</code> data (consider millions of vectors/matrices/objects).

blocks|key|312110|text|如果您需要一个不可复制构造的动态对象数组，那么指向数组的智能指针就是最佳选择。例如，如果您需要一个原子数组，该怎么办？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|312111|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you need a dynamic array of objects that are not copy-constructible, then a smart pointer to an array is the way to go. For example, what if you need an array of atomics.

<code>std::unique_ptr</code> has support for arrays, for instance:

<pre><code>std::unique_ptr&lt;int[]&gt; p(new int[10]);
</code></pre>

but is it needed? probably it is more convenient to use <code>std::vector</code> or <code>std::array</code>.

Do you find any use for that construct?

Is there any use for unique_ptr with array?

Visual Studio

游戏引擎

数据结构

编译器

std::unique_ptr支持数组，例如：std::unique_ptr<int[]> p(new int[10]);但这是必要的吗？也许使用std::vector或std::array更方便。你觉得这个结构有什么用处吗？

问unique_ptr对数组有什么用处吗？
EN

回答 11

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问unique_ptr对数组有什么用处吗？EN

回答 11

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问unique_ptr对数组有什么用处吗？
EN