Is there any use for unique_ptr with array?
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.
There are tradeoffs, and you pick the solution which matches what you want. Off the top of my head:
Initial size
vector
andunique_ptr<T[]>
allow the size to be specified at run-timearray
only allows the size to be specified at compile time
Resizing
array
andunique_ptr<T[]>
do not allow resizingvector
does
Storage
vector
andunique_ptr<T[]>
store the data outside the object (typically on the heap)array
stores the data directly in the object
Copying
array
andvector
allow copyingunique_ptr<T[]>
does not allow copying
Swap/move
vector
andunique_ptr<T[]>
have O(1) timeswap
and move operationsarray
has O(n) timeswap
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 onswap()
unique_ptr<T[]>
has no iterators; pointers and references are only invalidated byswap()
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
andvector
are both Containersunique_ptr<T[]>
is not a Container
I do have to admit, this looks like an opportunity for some refactoring with policy-based design.