std::dynarray vs std::vector

C++14 presents std::dynarray:

std::dynarray is a sequence container that encapsulates arrays with a size that is fixed at construction and does not change throughout the lifetime of the object.

std::dynarray must be allocated in run-time as same as std::vector.

So what are the benefits and the usage of std::dynarray while we can use std::vector which is more dynamic (and also re-sizable)?

Solution 1:

So what are the benefits and the usage of std::dynarray, when we can use std::vector which is more dynamic (Re-sizable)?

dynarray is smaller and simpler than vector, because it doesn't need to manage separate size and capacity values, and it doesn't need to store an allocator.

However the main performance benefit is intended to come from the fact that implementations are encouraged to allocate dynarray on the stack when possible, avoiding any heap allocation. e.g.

std::dynarray<int> d(5);   // can use stack memory for elements
auto p = new std::dynarray<int>(6);  // must use heap memory for elements

This optimisation requires cooperation from the compiler, it can't be implemented as a pure library type, and the necessary compiler magic has not been implemented and noone is sure how easy it is to do. Because of the lack of implementation experience, at the C++ committee meeting in Chicago last week it was decided to pull std::dynarray from C++14 and to issue a separate array extensions TS (technical specification) document defining std::experimental::dynarray and arrays of runtime bound (ARBs, similar to C99 VLAs.) This means std::dynarray will almost certainly not be in C++14.

Solution 2:

As you said yourself, std::dynarray is for a fixed-size dynamic array. It is not resizable. It's roughly speaking an improvement over new T[N] and over std::unique_ptr<T[]>(new T[N]).

Not needing to resize or manage capacity means you can implement the data structure with less complexity and in less space.

Moreover, std::dynarray is a weird animal that allows the implementation to implement it in different, non-specific ways, e.g. it's possible to put the array on the stack. Calling an allocation function is "optional". You can specify an allocator to construct the elements of the array, but that is not part of the type.

You might also wonder why we need std::dynarray and variable-length arrays. VLAs in C++14 are much more restrictive; they can only be local, automatic variables and offer no way to specify an allocation policy, and of course they don't have a standard container interface.

Some examples from 23.3.4.2 of a "current draft" (take that, Google cache):

explicit dynarray(size_type c);

Effects: Allocates storage for c elements. May or may not invoke the global operator new.

template <class Alloc>
dynarray(size_type c, const Alloc& alloc);

Effects: Equivalent to the preceding constructors except that each element is constructed with uses-allocator construction.

Whether or not you can use a given allocator to construct the array elements is a global trait:

template struct uses_allocator, Alloc> : true_type { };

Requires: Alloc shall be an Allocator (17.6.3.5). [Note: Specialization of this trait informs other library components that dynarray can be constructed with an allocator, even though it does not have a nested allocator_type.]

Edit: Jonathan Wakely's answer is bound to be far more authoritative and insightful.