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