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).



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.


Reply via email to