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/

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!

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.

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.

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

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;

?

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

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?

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);
}
----

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'