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