Allocators and Containers
Jack Stouffer via Digitalmars-d
digitalmars-d at puremagic.com
Thu Feb 16 07:48:44 PST 2017
On Thursday, 16 February 2017 at 15:37:52 UTC, Minty Fresh wrote:
> A lot of the usefulness of the std.experimental.allocators
> module is lost because no other part of the stdlib actually
> ties into the functionality provided by it.
The current rule of the standard library is that stuff outside of
experimental is not allowed to use experimental, because, well,
it's experimental. It's likely to break.
> For example, the Array type defined in std.container relies on
> malloc() directly, so if you wanted to use a type to replace
> built-in arrays with a custom allocator, you'd need to
> implement your own container type.
>
> Would it make sense to allow the std.container types to accept
> IAllocator instances, and to allow custom allocators? (Using
> Mallocator by default.)
The current std.containers design was not designed with
allocators in mind. The current plan is
1. DIP1000, which adds safety checks for escape analysis to the
language, must be completely implemented in order to have @safe
containers
2. A new containers design will be submitted to std.experimental
to eventually replace the current one
In the mean time you can always use
https://code.dlang.org/packages/emsi_containers
More information about the Digitalmars-d
mailing list