Thread overview | |||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
March 12, 2019 memory management and the standard library | ||||
---|---|---|---|---|
| ||||
So I pop in every now and then to look how D is progressing, and the last time I concidered D was for a problem a friend of me had with a small game. In that game there was some colission detection that required a custom datastructure and then some operations on top of that, with a hard limit on time. For this I concidered using D for all its metaprogramming, but I couldn't find how people use manual memory management for common types in the standard library. Is there no way to use custom memory management for types as strings, arrays, every function in the std.algorith module and slices? Am I missing something obvious? What's the view of the creators of D with regards to custom (manual or gc) memory management for the standard library? C++ Makes a template of about everything that could allocate just so it can extract the allocator. (std::vector for instance) Will D do that too? Will D use a different approach or conclude that this problem only exists for a select few and not the main audience of D? |
March 13, 2019 Re: memory management and the standard library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sjoerd Nijboer | The allocator API is experimental, so currently only 3rd party libraries use manual memory management. |
March 13, 2019 Re: memory management and the standard library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sjoerd Nijboer | On Tuesday, 12 March 2019 at 21:12:49 UTC, Sjoerd Nijboer wrote: > So I pop in every now and then to look how D is progressing, and the last time I concidered D was for a problem a friend of me had with a small game. In that game there was some colission detection that required a custom datastructure and then some operations on top of that, with a hard limit on time. > > For this I concidered using D for all its metaprogramming, but I couldn't find how people use manual memory management for common types in the standard library. Is there no way to use custom memory management for types as strings, arrays, every function in the std.algorith module and slices? Am I missing something obvious? > > What's the view of the creators of D with regards to custom (manual or gc) memory management for the standard library? C++ Makes a template of about everything that could allocate just so it can extract the allocator. (std::vector for instance) Will D do that too? Will D use a different approach or conclude that this problem only exists for a select few and not the main audience of D? std.algorithm mostly doesn't care about allocations. I guess one *could* want to control how the returned ranges are allocated, but I'm not sure how useful that would be. Otherwise, I wrote this: https://github.com/atilaneves/automem |
March 13, 2019 Re: memory management and the standard library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sjoerd Nijboer | On 3/12/19 5:12 PM, Sjoerd Nijboer wrote:
> ...
> What's the view of the creators of D with regards to custom (manual or gc) memory management for the standard library? C++ Makes a template of about everything that could allocate just so it can extract the allocator. (std::vector for instance) Will D do that too? Will D use a different approach or conclude that this problem only exists for a select few and not the main audience of D?
Partially related: I believe a recent (most recent?) version of D allows pluggable garbage collector, although I am not aware of any plugins just yet.
|
March 13, 2019 Re: memory management and the standard library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On Wednesday, 13 March 2019 at 08:22:30 UTC, Kagamin wrote:
> The allocator API is experimental, so currently only 3rd party libraries use manual memory management.
If the allocator API would become non experimental, would there be any attempt to extract allocators out using templates?
|
March 13, 2019 Re: memory management and the standard library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | On Wednesday, 13 March 2019 at 09:05:27 UTC, Atila Neves wrote:
> std.algorithm mostly doesn't care about allocations. I guess one *could* want to control how the returned ranges are allocated, but I'm not sure how useful that would be.
>
> Otherwise, I wrote this:
>
> https://github.com/atilaneves/automem
Automem with the vector template looks like i would expect D's arrays to be. Will we ever get something like this in the stdlib?
|
March 13, 2019 Re: memory management and the standard library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sjoerd Nijboer | On Wednesday, 13 March 2019 at 16:34:29 UTC, Sjoerd Nijboer wrote: > On Wednesday, 13 March 2019 at 08:22:30 UTC, Kagamin wrote: >> The allocator API is experimental, so currently only 3rd party libraries use manual memory management. > > If the allocator API would become non experimental, would there be any attempt to extract allocators out using templates? What do you mean by this? You can already use the allocator API today, though I would recommend to use the DUB package [1] as the API there is frozen and thus won't break with potential changes. Also v3 of the DUB package [1] works with BetterC. [1] https://github.com/dlang-community/stdx-allocator |
March 13, 2019 Re: memory management and the standard library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sjoerd Nijboer | On Wednesday, 13 March 2019 at 16:45:35 UTC, Sjoerd Nijboer wrote: > On Wednesday, 13 March 2019 at 09:05:27 UTC, Atila Neves wrote: >> std.algorithm mostly doesn't care about allocations. I guess one *could* want to control how the returned ranges are allocated, but I'm not sure how useful that would be. >> >> Otherwise, I wrote this: >> >> https://github.com/atilaneves/automem > > Automem with the vector template looks like i would expect D's arrays to be. Will we ever get something like this in the stdlib? Maybe, see e.g. https://github.com/dlang/druntime/pull/2348 Though Phobos has been declared "stable" these days, which means that breaking changes can't be done anymore and if you're looking for sth. modern and nice, dub is the place these days. I wonder if we ever get to the point where we can replace Phobos with a modern standard library... |
March 13, 2019 Re: memory management and the standard library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Seb | On Wednesday, 13 March 2019 at 17:50:57 UTC, Seb wrote: > [...] > Though Phobos has been declared "stable" these days, which means that breaking changes can't be done anymore and if you're looking for sth. modern and nice, dub is the place these days. > I wonder if we ever get to the point where we can replace Phobos with a modern standard library... https://github.com/wilzbach/hellas Do you have any plans for this? |
March 14, 2019 Re: memory management and the standard library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Francesco Mecca | On Wednesday, 13 March 2019 at 19:22:37 UTC, Francesco Mecca wrote: > On Wednesday, 13 March 2019 at 17:50:57 UTC, Seb wrote: >> [...] >> Though Phobos has been declared "stable" these days, which means that breaking changes can't be done anymore and if you're looking for sth. modern and nice, dub is the place these days. >> I wonder if we ever get to the point where we can replace Phobos with a modern standard library... > > https://github.com/wilzbach/hellas > Do you have any plans for this? Yes, I do (if I ever get time to get it). The rough outline is here: https://github.com/wilzbach/dts/issues The rough vision of dts is to remove the ugly bits of Phobos that we can't remove or change and make the design/structure more fitting. However, there are a few limiting language/runtime issues like D strings being used for exceptions etc. Anyhow, I should probably point out that Jonathan is pushing a more radical approach with Dragon: https://github.com/dragon-lang The main vision of Dragon is to do the radical D3 changes that would never be accepted in mainline dmd, see e.g. https://github.com/dragon-lang/dc/issues/43 |
Copyright © 1999-2021 by the D Language Foundation