From: Christian Mazakas (christian.mazakas_at_[hidden])
Date: 2020-01-23 04:04:22
I've been working on an AllocatorAwareContainer called `dynamic_array` and
was wondering if there'd be any interest in including it in Boost.
First and foremost, a link to the source code:
`dynamic_array` is a heap-allocated array that can't be resized (without
entirely re-assigning it). It's useful in cases where you'd normally use
`std::vector` but have no need of `push_back`, `emplace_back`, or any of
the other size modifiers that the container supports. These kinds of arrays
are typically useful in I/O applications which normally only accept a
pointer-size pair to write out to.
Naturally the question arises, "why use `dynamic_array` in the year 2020
when we have `std::vector` and `boost::allocate_unique`?".
`std::vector` imposes a constant storage cost of pointer, size, and
capacity. `dynamic_array` only stores a pointer and a size making it
slimmer in use-cases where there's no need of a separation between size and
capacity. `dynamic_array` also supports constructors `std::vector` doesn't
have. For example, `dynamic_array` is constructible from a Range and has a
`noinit` constructor. `dynamic_array` even supports array objects which
gives it another advantage.
`boost::allocate_unique` is a significantly tougher class to beat because
it boasts many of the same features: a dynamic allocation done using the
supplied Allocator supporting `noinit` construction and array objects with
a size (stored in the Deleter of the returned `std::unique_ptr`). And while
it is true that `boost::allocate_unique` enables all of this, it still
lacks a few key semantics.
Namely, `dynamic_array` is copyable. It's also copy assignable and move
assignable, including the case where the underlying allocators do not use
the same memory resource and will instead perform a piece-wise move of the
It's arguable whether or not `std::unique_ptr` should support similar
semantics so in the interim, `dynamic_array` is the next best thing.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk