diff options
Diffstat (limited to 'source/blender/blenlib/BLI_array.hh')
-rw-r--r-- | source/blender/blenlib/BLI_array.hh | 21 |
1 files changed, 19 insertions, 2 deletions
diff --git a/source/blender/blenlib/BLI_array.hh b/source/blender/blenlib/BLI_array.hh index 07155439170..25267bc65d6 100644 --- a/source/blender/blenlib/BLI_array.hh +++ b/source/blender/blenlib/BLI_array.hh @@ -27,8 +27,7 @@ * blender::Array should usually be used instead of blender::Vector whenever the number of elements * is known at construction time. Note however, that blender::Array will default construct all * elements when initialized with the size-constructor. For trivial types, this does nothing. In - * all other cases, this adds overhead. If this becomes a problem, a different constructor which - * does not do default construction can be added. + * all other cases, this adds overhead. * * A main benefit of using Array over Vector is that it expresses the intent of the developer * better. It indicates that the size of the data structure is not expected to change. Furthermore, @@ -130,6 +129,24 @@ class Array { uninitialized_fill_n(m_data, m_size, value); } + /** + * Create a new array with uninitialized elements. The caller is responsible for constructing the + * elements. Moving, copying or destructing an Array with uninitialized elements invokes + * undefined behavior. + * + * This should be used very rarely. Note, that the normal size-constructor also does not + * initialize the elements when T is trivially constructible. Therefore, it only makes sense to + * use this with non trivially constructible types. + * + * Usage: + * Array<std::string> my_strings(10, NoInitialization()); + */ + Array(uint size, NoInitialization) + { + m_size = size; + m_data = this->get_buffer_for_size(size); + } + Array(const Array &other) : m_allocator(other.m_allocator) { m_size = other.size(); |