www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Allocators and Containers

reply Minty Fresh <mint fresh.com> writes:
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.

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.)
Feb 16 2017
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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
Feb 16 2017
next sibling parent Seb <seb wilzba.ch> writes:
On Thursday, 16 February 2017 at 15:48:44 UTC, Jack Stouffer 
wrote:

 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.


Yep, for reference please see this thread: 
http://forum.dlang.org/post/hxwadyrnvzvutrdcgsdp forum.dlang.org

tld;dr: Current blockers are:
- no CTFE support
- dependent on druntime
Feb 16 2017
prev sibling parent reply Jon Degenhardt <jond noreply.com> writes:
On Thursday, 16 February 2017 at 15:48:44 UTC, Jack Stouffer 
wrote:

 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


This is very useful information. Is there a thread or document 
describing this further? I'm not looking for hard decisions. Just 
that it's useful to have bigger picture view of what is on the 
horizon. If there's nothing readily available, perhaps a talk at 
DConf?

--Jon
Feb 16 2017
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Friday, 17 February 2017 at 03:05:04 UTC, Jon Degenhardt wrote:

 This is very useful information. Is there a thread or document 
 describing this further? I'm not looking for hard decisions. 
 Just that it's useful to have bigger picture view of what is on 
 the horizon. If there's nothing readily available, perhaps a 
 talk at DConf?

 --Jon


This is based on conversations I've had with Andrei and Walter on 
here and on Github.

There was a bunch of threads here about six months ago by Andrei 
talking about the different problems he was running into when 
trying to implement  safe and  nogc containers. One of the 
conclusions was that ref counting was going to have to be a 
nessesary component of the solution. This led to DIP1000 because 
of Andrei's conclusion that "Safe reference counting cannot be 
implemented as a library" 
https://forum.dlang.org/post/n0nnu0$1tth$1 digitalmars.com.

Also, there's the vision document, which lays out some goals but 
does not talk about containers: 
https://wiki.dlang.org/Vision/2017H1
Feb 16 2017
parent Jon Degenhardt <jond noreply.com> writes:
On Friday, 17 February 2017 at 04:13:06 UTC, Jack Stouffer wrote:

 This is based on conversations I've had with Andrei and Walter 
 on here and on Github.

 There was a bunch of threads here about six months ago by 
 Andrei talking about the different problems he was running into 
 when trying to implement  safe and  nogc containers. One of the 
 conclusions was that ref counting was going to have to be a 
 nessesary component of the solution. This led to DIP1000 
 because of Andrei's conclusion that "Safe reference counting 
 cannot be implemented as a library" 
 https://forum.dlang.org/post/n0nnu0$1tth$1 digitalmars.com.

 Also, there's the vision document, which lays out some goals 
 but does not talk about containers: 
 https://wiki.dlang.org/Vision/2017H1


Excellent, thanks for sharing this.  --Jon
Feb 16 2017
prev sibling parent Basile B. <b2.temp gmx.com> writes:
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.

 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.)


Appender also, although there some WIP for a complete  nogc 
version (which I'd prefer to be based on allocators too, but well 
not possible b/c of the reasons mentioned above).
Feb 16 2017