From: Gavin Lambert (boost_at_[hidden])
Date: 2020-06-17 22:56:33
On 17/06/2020 22:01, degski wrote:
> Another approach worth exploring in my opinion is *to change 'the
> allocator' from being a std-node-allocator to being a node=allocator that
> 'dispenses' from a std::vector.* Such an 'allocator' exists, i.e.
> 'plf::colony'. Now our LL (the ring) has vector-allocation-patterns behind
> it [see docs plf::colcony], with an added benefit: the nodes are like with
> std::allocator never moved. The latter is currently (due to implementation
> details, which will change) not strictly true, notably reserve() moves
> objects (reserve() is not usable with non-movable objects), but plf::colony
> is otherwise well usable for non-movable-non-copyable types (contrary to
> what is said in the docs). I have written a PoC
> <https://github.com/degski/this_local/blob/b6305194e14de6c6678cea6a847d1aee0021d2b1/include/this_local/this_local/detail/this_local/detail.hpp#L503>
Using an interface that requires throwing an exception to indicate
"buffer full" (due to failure to allocate a new node from a
fixed-capacity buffer, and allocators lacking any other means to
indicate allocation failure) doesn't seem entirely desirable.