Jump to page: 1 24  
Page
Thread overview
memory management and the standard library
Mar 12, 2019
Sjoerd Nijboer
Mar 13, 2019
Kagamin
Mar 13, 2019
Sjoerd Nijboer
Mar 13, 2019
Seb
Mar 13, 2019
Atila Neves
Mar 13, 2019
Sjoerd Nijboer
Mar 13, 2019
Seb
Mar 13, 2019
Francesco Mecca
Mar 14, 2019
Seb
Mar 14, 2019
Paolo Invernizzi
Mar 14, 2019
JN
Mar 14, 2019
H. S. Teoh
Mar 14, 2019
Seb
Mar 15, 2019
H. S. Teoh
Mar 17, 2019
Jacob Carlborg
Mar 17, 2019
H. S. Teoh
Mar 15, 2019
James Blachly
Mar 15, 2019
Paulo Pinto
Mar 15, 2019
Kagamin
Mar 16, 2019
Olivier FAURE
Mar 16, 2019
Jacob Carlborg
Mar 16, 2019
Olivier FAURE
Mar 17, 2019
James Blachly
Mar 17, 2019
rikki cattermole
Mar 17, 2019
Jacob Carlborg
Mar 17, 2019
Johannes Pfau
Mar 18, 2019
Jacob Carlborg
Mar 18, 2019
Olivier FAURE
Mar 17, 2019
Sjoerd Nijboer
Mar 18, 2019
Olivier FAURE
Mar 19, 2019
Atila Neves
Mar 17, 2019
Paolo Invernizzi
Mar 13, 2019
James Blachly
March 12, 2019
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
The allocator API is experimental, so currently only 3rd party libraries use manual memory management.
March 13, 2019
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
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
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
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
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
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
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
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
« First   ‹ Prev
1 2 3 4