www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Blog post on automem

reply Mike Parker <aldacron gmail.com> writes:
Atila was kind enough to do a write up on his automem library for 
the D Blog, talking about why he did it and showing some of the 
implementation details. This is officially part of the GC series. 
The next post in the series will be my  nogc post (I've pushed it 
back to after DConf).

When I publish the next one, I'll add a page to the blog with 
each post in the series linked under two categories: 'GC 
Fundamentals' and 'Memory Management Strategies'. Atila's post 
sits squarely in the latter. If you have a particular strategy 
you use for working with D's GC, please let me know and we can 
talk about a post (guest post or otherwise).

Blog:
https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/

Reddit:
https://www.reddit.com/r/programming/comments/682xzc/automem_a_library_for_cstyle_raii_in_d/
Apr 28
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:
 Atila was kind enough to do a write up on his automem library 
 for the D Blog, talking about why he did it and showing some of 
 the implementation details. This is officially part of the GC 
 series. The next post in the series will be my  nogc post (I've 
 pushed it back to after DConf).
I was just looking at automem, but it's nice to have a blog post written up too!
Apr 28
prev sibling next sibling parent reply Swoorup Joshi <swoorupjoshi gmail.com> writes:
On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:
 Atila was kind enough to do a write up on his automem library 
 for the D Blog, talking about why he did it and showing some of 
 the implementation details. This is officially part of the GC 
 series. The next post in the series will be my  nogc post (I've 
 pushed it back to after DConf).

 [...]
Automem is something, that should just be there in the standard library.
Apr 28
parent reply qznc <qznc web.de> writes:
On Friday, 28 April 2017 at 15:39:07 UTC, Swoorup Joshi wrote:
 On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:
 Atila was kind enough to do a write up on his automem library 
 for the D Blog, talking about why he did it and showing some 
 of the implementation details. This is officially part of the 
 GC series. The next post in the series will be my  nogc post 
 (I've pushed it back to after DConf).

 [...]
Automem is something, that should just be there in the standard library.
There is a RefCounted in std.typecons as well. The article does not explain the differences though.
Apr 28
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 04/28/2017 11:26 AM, qznc wrote:

 There is a RefCounted in std.typecons as well. The article does not
 explain the differences though.
The article gives a difference: <quote> D’s standard library has Unique and RefCounted in std.typecons but they predate std.experimental.allocator and so “bake in” the allocation strategy. </quote> Ali
Apr 28
prev sibling next sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:
 Blog:
 https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/
Nice. One thing, Atila; what about replacing typeof(u1) u2; move(u1, u2); with typeof(u1) u2 = move(u1); or, alternatively, typeof(u1) u2 = u1.move; ?
Apr 28
parent Atila Neves <atila.neves gmail.com> writes:
On Friday, 28 April 2017 at 22:06:57 UTC, Nordlöw wrote:
 On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:
 Blog:
 https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/
Nice. One thing, Atila; what about replacing typeof(u1) u2; move(u1, u2); with typeof(u1) u2 = move(u1); or, alternatively, typeof(u1) u2 = u1.move; ?
I only learned about the single argument move when Manu did the other day in his thread! I just changed the code and the README.md to read like your last example. Atila
Apr 28
prev sibling next sibling parent reply ANtlord <antlord92 gmail.com> writes:
On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:
 When I publish the next one, I'll add a page to the blog with 
 each post in the series linked under two categories: 'GC 
 Fundamentals' and 'Memory Management Strategies'. Atila's post 
 sits squarely in the latter. If you have a particular strategy 
 you use for working with D's GC, please let me know and we can 
 talk about a post (guest post or otherwise).
As far as I know a delegate depends on GC. Can this library help to solve this?
May 03
parent ag0aep6g <anonymous example.com> writes:
On 05/03/2017 01:05 PM, ANtlord wrote:
 As far as I know a delegate depends on GC.
Closures depend on the GC. Not all delegates involve closures. For example, you don't need the GC to make a delegate of a method: ---- struct S { int x = 0; void m() nogc { x = 1; } } void main() nogc { S s; void delegate() nogc dg = &s.m; dg(); assert(s.x == 1); } ----
May 03
prev sibling parent reply ANtlord <antlord92 gmail.com> writes:
On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:
 Atila was kind enough to do a write up on his automem library 
 for the D Blog, talking about why he did it and showing some of 
 the implementation details. This is officially part of the GC 
 series. The next post in the series will be my  nogc post (I've 
 pushed it back to after DConf).

 When I publish the next one, I'll add a page to the blog with 
 each post in the series linked under two categories: 'GC 
 Fundamentals' and 'Memory Management Strategies'. Atila's post 
 sits squarely in the latter. If you have a particular strategy 
 you use for working with D's GC, please let me know and we can 
 talk about a post (guest post or otherwise).

 Blog:
 https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/

 Reddit:
 https://www.reddit.com/r/programming/comments/682xzc/automem_a_library_for_cstyle_raii_in_d/
Does it possible to use the library with classes? I have a simple code that can't be compiled due to GC calling. import automem.unique : Unique; import std.experimental.allocator.mallocator: Mallocator; class MyClass { int a; this(int a) nogc { this.a = a; } ~this() nogc { } } void main() nogc { auto obj = Unique!(MyClass, Mallocator)(1); } Text of error is nogc function 'D main' cannot call non- nogc destructor 'automem.unique.Unique!(MyClass, Mallocator).Unique.~this'
May 03
parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 3 May 2017 at 12:43:26 UTC, ANtlord wrote:
 On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:
 Atila was kind enough to do a write up on his automem library 
 for the D Blog, talking about why he did it and showing some 
 of the implementation details. This is officially part of the 
 GC series. The next post in the series will be my  nogc post 
 (I've pushed it back to after DConf).

 When I publish the next one, I'll add a page to the blog with 
 each post in the series linked under two categories: 'GC 
 Fundamentals' and 'Memory Management Strategies'. Atila's post 
 sits squarely in the latter. If you have a particular strategy 
 you use for working with D's GC, please let me know and we can 
 talk about a post (guest post or otherwise).

 Blog:
 https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/

 Reddit:
 https://www.reddit.com/r/programming/comments/682xzc/automem_a_library_for_cstyle_raii_in_d/
Does it possible to use the library with classes? I have a simple code that can't be compiled due to GC calling. import automem.unique : Unique; import std.experimental.allocator.mallocator: Mallocator; class MyClass { int a; this(int a) nogc { this.a = a; } ~this() nogc { } } void main() nogc { auto obj = Unique!(MyClass, Mallocator)(1); } Text of error is nogc function 'D main' cannot call non- nogc destructor 'automem.unique.Unique!(MyClass, Mallocator).Unique.~this'
I took a look at this. It's a druntime problem. Unique.~this calls std.experimental.allocator.dispose, which calls destroy in object.d which calls rt_finalize: extern (C) void rt_finalize(void *data, bool det=true); Notice the lack of ` nogc` in the declaration. Adding the annotation should fix the problem, assuming the implementation is in fact ` nogc`. I'll file a bug and PR to fix it. Atila
May 04
next sibling parent Nick Treleaven <nick geany.org> writes:
On Thursday, 4 May 2017 at 08:41:55 UTC, Atila Neves wrote:
 I took a look at this. It's a druntime problem. Unique.~this 
 calls std.experimental.allocator.dispose, which calls destroy 
 in object.d which calls rt_finalize:

 extern (C) void rt_finalize(void *data, bool det=true);

 Notice the lack of ` nogc` in the declaration. Adding the 
 annotation should fix the problem, assuming the implementation 
 is in fact ` nogc`. I'll file a bug and PR to fix it.
Bug: https://issues.dlang.org/show_bug.cgi?id=17297
May 04
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Thursday, 4 May 2017 at 08:41:55 UTC, Atila Neves wrote:
 On Wednesday, 3 May 2017 at 12:43:26 UTC, ANtlord wrote:
 [...]
I took a look at this. It's a druntime problem. Unique.~this calls std.experimental.allocator.dispose, which calls destroy in object.d which calls rt_finalize: extern (C) void rt_finalize(void *data, bool det=true); Notice the lack of ` nogc` in the declaration. Adding the annotation should fix the problem, assuming the implementation is in fact ` nogc`. I'll file a bug and PR to fix it. Atila
There already is a bug, apparently: https://issues.dlang.org/show_bug.cgi?id=17297 Atila
May 04