On Thursday, 24 March 2016 at 11:18:06 UTC, Nordlöw wrote:
Could somebody briefly outline how the thread-locality
(non-GC-locked) of allocators relates to the purity of the
containers using them?
This because I want to move forward with optimizations in my
knowledge graph that requires GC-free array containers storing
value typed elements (integers) which preferrably has pure API.
Specifically, I want to use something like
https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d
that is `@safe pure` and uses lock-free allocations in a
heavily multi-threaded application.
If I want purity aswell which `std.experimental.allocators` are
possible?
After a quick glance at:
https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d
It looks like if `useGC == false`, all of the methods should be
`pure`-ready, except for `remove(size_t)` and `~this()`. These
two methods use `typeid.destroy`, which I don't think is `pure`.
