I interface to a C library that gives me a malloced object. How can I manage that pointer so that it gets freed automatically.
What I've thought of so far:

• scope(exit): not an option because I want to return that memory
• struct wrapper: Doesn't work because if I pass it to another function, they also destroy it (sometimes). Also same problem as with scope(exit)
• struct wrapped in automem/ refcounted: The struct still leaves original scope and calls the destructor

On 10/6/21 2:06 PM, anon wrote:

If the memory is the only resource it is consuming, you can use a GC-allocated wrapper.

This is how I would do it:

struct GCWrapped(T)
{
   private T *_val;
   this(T* val) { _val = val; }
   ref T get() { return *_val; }
   alias get this; // automatically unwrap
   ~this() { free(_val); _val = null; }
   @disable this(this); // disable copying to avoid double-free
}

GCWrapped!T *wrap(T)(T *item) {
  return new GCWrapped!T(item);
}

// usage
auto wrapped = wrap(cFunction());

// use wrapped wherever you need to access a T.

You can return this thing and pass it around, and the GC will keep it alive until it's not needed. Then on collection, the value is freed.

If this contains a non-memory resource, such as a file or socket, then those are much more limited, and you probably want to use deterministic destruction instead.

-Steve

Thanks for the help.

On Wednesday, 6 October 2021 at 18:29:34 UTC, Steven Schveighoffer wrote:

Sorry for messed up post, fixed it.

On Wednesday, 6 October 2021 at 18:29:34 UTC, Steven Schveighoffer wrote:

Is the gc required to call ~this() on the struct? I remember it being implementation defined. Probably doesn't matter for my usecase, just curious.

Yes I'm afraid of double freeing. How do I pass existing struct to refcounted without the already existing copy calling destructed on function exit.

I found https://dlang.org/library/std/typecons/unique.html , which I think solves my problem by disabling copying. Thanks for the help.

On 10/6/21 3:22 PM, anon wrote:

The GC is technically not required to free any blocks ever. But in general, it does.

When it does free a struct, as long as you allocated with new, it should call the dtor.

Just FYI, you should reply to the posts that you quote, or at least copy the "X Y wrote" line so people understand the thread. This question was written by H.S. Teoh, but I'll respond.

The destructor is called once per copy. This is why disabling copy prevents double freeing.

There are cases where the compiler avoids calling the destructor because the instance is moved. Such as returning a newly constructed item (typically referred to as an "rvalue"), or passing a newly constructed item into a parameter. The parameter will be destroyed, but the call-site constructed item will not.

e.g.:

struct S
{
   int x;
   ~this() { writeln("destructor called"); }
}

void foo(S s) {

   // destructor for s called here
}

S makeS(int x)
{
   return S(x); // no destructor called here.
}

void main()
{
   foo(S(1)); // no destructor called for this rvalue
   auto s = makeS(1);
   // destructor for s called here.
   foo(makeS(1)); // only one destructor called at the end of foo
}

You can also use std.algorithm.move to avoid calling destructors on live data. However, the destructor will still be called, it just will be called on an S.init value.

-Steve

On Thursday, 7 October 2021 at 11:55:35 UTC, Steven Schveighoffer wrote:

In practice when I played around with it, destructor always got called by GC. But: https://dlang.org/spec/class.html#destructors says at point 6:

Alright. If I want to reply to multiple people, should I post twice or quote both in the same post?

struct S
{
   int x;
   ~this() { writeln("destructor called"); }
}

void foo(S s) {

   // destructor for s called here
}

S makeS(int x)
{
   return S(x); // no destructor called here.
}

void main()
{
   foo(S(1)); // no destructor called for this rvalue
   auto s = makeS(1);
   // destructor for s called here.
   foo(makeS(1)); // only one destructor called at the end of foo
}

Is there any reference for exactly how these rules apply, or is this implementation defined? The specification says that destructors are called when objects go out of scope. Your examples seem to suggest that this is untrue in some cases.

On Wednesday, 6 October 2021 at 18:06:38 UTC, anon wrote:

Explain again why scope exit isn't an option

On Monday, 11 October 2021 at 12:09:07 UTC, Imperatorn wrote:

The explanation is "I want to return that memory".

int* not_an_option() {
    import core.memory : pureMalloc, pureFree;

    int* p = cast(int*) pureMalloc(int.sizeof);
    scope (exit)
        pureFree(p);
    return p;
}

unittest {
    not_an_option()[0] = 1;
}

valgrind: Invalid write of size 4