Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk