Take the 2-minute tour ×

std::unique_ptr has support for arrays, for instance:


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

Do you find any use for that construct?

share|improve this question
For completeness, I should point out that there is no std::shared_ptr<T[]>, but there should be, and probably will be in C++14 if anyone could be bothered to write up a proposal. In the mean time, there's always boost::shared_array. –  Pseudonym May 30 at 0:23
add comment

5 Answers

up vote 31 down vote accepted

Some people do not have the luxury of using std::vector, even with allocators. Some people need a dynamically sized array, so std::array is out. And some people get their arrays from other code that is known to return an array; and that code isn't going to be rewritten to return a vector or something.

By allowing unique_ptr<T[]>, you service those needs.

In short, you use unique_ptr<T[]> when you need to. When the alternatives simply aren't going to work for you. It's a tool of last resort.

share|improve this answer
your first argument makes no sense to me... what is the reason to use up that poins to heap allocated mem instead of vector + reserve? –  NoSenseEtAl May 30 at 15:46
@NoSenseEtAl: I'm not sure what part of "some people aren't allowed to do that" eludes you. Some projects have very specific requirements, and among them may be "you don't get to use vector". You can argue whether those are reasonable requirements or not, but you can't deny that they exist. –  Nicol Bolas May 30 at 15:48
ok, i see, i thought by luxury you meant perf considerations, not ignorance :) –  NoSenseEtAl May 30 at 16:27
btw im not downvoter , though like I said i find luxury to be unfortunate word here :) nice answer in general –  NoSenseEtAl May 31 at 8:07
add comment

There are tradeoffs, and you pick the solution which matches what you want. Off the top of my head:

Initial size

  • vector and unique_ptr<T[]> allow the size to be specified at run-time
  • array only allows the size to be specified at compile time


  • array and unique_ptr<T[]> do not allow resizing
  • vector does


  • vector and unique_ptr<T[]> store the data outside the object (typically on the heap)
  • array stores the data directly in the object


  • array and vector allow copying
  • unique_ptr<T[]> does not allow copying


  • vector and unique_ptr<T[]> have O(1) time swap and move operations
  • array has O(n) time swap and move operations, where n is the number of elements in the array

Pointer/reference/iterator invalidation

  • 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).

Compatibility with concepts and algorithms

  • array and vector are both Containers
  • unique_ptr<T[]> is not a Container

I do have to admit, this looks like an opportunity for some refactoring with policy-based design.

share|improve this answer
I am not sure I understand what you mean in the context of pointer invalidation. Is this about pointers to the objects themselves, or pointers to the elements? Or something else? What kind of guarantee do you get from an array that you don't get from a vector? –  jogojapan May 29 at 2:52
Suppose that you have an iterator, a pointer, or a reference to an element of a vector. Then you increase the size or capacity of that vector such that it forces a reallocation. Then that iterator, pointer or reference no longer points to that element of the vector. This is what we mean by "invalidation". This problem doesn't happen to array, because there is no "reallocation". Actually, I just noticed a detail with that, and I've edited it to suit. –  Pseudonym May 29 at 3:33
Ok, there can't be invalidation as a result of reallocation in an array or unique_ptr<T[]> because there is no reallocation. But of course, when the array goes out of scope, pointers to specific elements will still be invalidated. –  jogojapan May 29 at 3:38
Yes, all bets are off if the object is no longer live. –  Pseudonym May 29 at 3:43
Although unique_ptr<T[]> has no iterator built-in, you can still iterate over it like a normal T[], which means you need a size of the range to be iterated over. –  rubenvb May 29 at 8:43
show 1 more comment

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

share|improve this answer
Just because something can be copied around doesn't mean it has to be. –  Nicol Bolas May 23 at 10:41
@NicolBolas: I don't understand. One may want to prevent that for the same reason why one would use unique_ptr instead of shared_ptr. Am I missing something? –  Andy Prowl May 23 at 10:42
unique_ptr does more than just prevent accidental misuse. It's also smaller and lower overhead than shared_ptr. The point being that, while it's nice to have semantics in a class that prevent "misuse", that's not the only reason to use a particular type. And vector is far more useful as an array storage than unique_ptr<T[]>, if for no reason other than the fact that it has a size. –  Nicol Bolas May 23 at 10:43
I thought I made the point clear: there are other reasons to use a particular type than that. Just like there are reasons to prefer vector over unique_ptr<T[]> where possible, instead of just saying, "you can't copy it" and therefore pick unique_ptr<T[]> when you don't want copies. Stopping someone from doing the wrong thing is not necessarily the most important reason to pick a class. –  Nicol Bolas May 23 at 10:49
std::vector has more overhead than a std::unique_ptr -- it uses ~3 pointers instead of ~1. std::unique_ptr blocks copy construction but enables move construction, which if semantically the data you are working with can only be moved but not copied, infects the class containing the data. Having an operation on data that is not valid actually makes your container class worse, and "just don't use it" does not wash away all sins. Having to put every instance of your std::vector into a class where you manually disable move is a headache. std::unique_ptr<std::array> has a size. –  Yakk May 23 at 13:50
show 5 more comments

I have used unique_ptr 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).

share|improve this answer
add comment

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:

unique_ptr<byte[]> data = get_some_data();

threadpool->post_work([](void* param) { do_a_thing(unique_ptr<byte[]>((byte*)param)); },

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

share|improve this answer
add comment

Your Answer


