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