www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ETA: std.experimental.allocator -> std.allocator

reply Seb <seb wilzba.ch> writes:
Hi all,

tl;dr: I would like to start having GC-free methods and data 
structures in Phobos, which depends on std.allocator being stable 
(i.e not in experimental).
Q1: So I would like to know what's missing/blocking this? Is it 
just time?
(FYI: std.experimental.allocator has been merged in October 2015 
and released in November 2015 with 2.069)

One thing that I heard a bit is that there's no defined guideline 
on how Allocator APIs should look like. I have seen two good 
patterns so far that, but they both have their pros/cons. As I 
think this is very important when std.allocator will be used in 
Phobos I summarized them below to help everyone to get into the 
discussion.
Q2: What is your favorite Allocator API pattern and how should 
Phobos APIs facilitate opt-in GC-free algorithms/data structures?

Q3: Are there any plans on providing language support for custom 
allocators? E.g.

new int[10] -> theAllocator.makeArray
new FancyClass(foo) -> theAllocator.make!FancyClass(foo)


1) Allocator with GCAllocator as default argument
-------------------------------------------------

I think that's how most people use the Allocator. A prominent 
example is the EMSI's container library [1].
The basic idea is that by default all allocations are handled 
conveniently by the GCAllocator.

import std.experimental.allocator.gc_allocator: GCAllocator;

void myFun(Allocator = shared GCAllocator)(int foo, ref Allocator 
alloc = Allocator.instance)
{
     import std.experimental.allocator : makeArray, dispose;
     auto b = alloc.makeArray!int(10); // instead of new int[10]
     alloc.dispose(b);
}

unittest
{
     myFun(2);
     import std.experimental.allocator.mallocator: Mallocator;
     myFun(2, Mallocator.instance);
}

Please note that although since 2.072 for make/makeArray 
attributes are automatically propagated, due to the global 
sharedness of the GCAllocator such templated code can't be  safe 
(see e.g. [2] for a discussion).

2) makeX pattern
----------------

The idea here is to provide a special makeX method that allows 
the use of custom allocator.
This pattern is intended for cases in which allocated data is 
returned to the user.

A simplified example from Phobos:

auto slice(T, size_t N)(size_t[N] lengths...);
SliceAllocationResult!(N, T) makeSlice(T, Allocator, size_t 
N)(auto ref Allocator alloc, size_t[N] lengths...);

And a short usage example:

slice!int(2, 3);
Mallocator.instance.makeSlice!int(2, 3);

Another good example is mir.combinatorics [2].

The idea here is that it's the users job to deal with the 
allocated data, he has to call dispose himself. Thus a 
convenience dispose overload may be provided.

[1] https://github.com/economicmodeling/containers
[2] https://github.com/dlang/phobos/pull/4288
[3] 

[4] http://docs.mir.dlang.io/latest/mir_combinatorics.html
Dec 09 2016
next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
Q4: Current allocator API requires DRuntime to be linked. So, 
they are not compatible with BetterC mode. Can this be fixed 
before std.experimental.allocator -> std.allocator migration? 
--Ilya
Dec 09 2016
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-12-10 05:18, Seb wrote:

 Hi all,

 tl;dr: I would like to start having GC-free methods and data structures
 in Phobos, which depends on std.allocator being stable (i.e not in
 experimental).
 Q1: So I would like to know what's missing/blocking this?


I think it needs to be CTFE compatible. I also really don't like the 
name "theAllocator".

-- 
/Jacob Carlborg
Dec 10 2016