In the following code, the `_foo` pointer (of the Foo struct) is null in the first call to the destructor. Why is this? I think it's got something to do with the foreach loop but I'm not sure. Any ideas?


import std.stdio;
import core.stdc.stdlib : malloc, calloc, free;

struct Foo
{
	public int* _foo;

	public this(int n)
	{
		this._foo  = cast(int*) malloc(int.sizeof);
		writefln("ctor: %x", this._foo);
	}

	public this(this)
	{
		writefln("post blit: %x", this._foo);
	}

	public ~this()
	{
		// Why is this._foo null here???
		writefln("dtor: %x", this._foo);
	}
}

struct Bar
{
	private Foo[] _data;

	public this(int n)
	{
		this._data = (cast(Foo*) calloc(n, Foo.sizeof))[0 .. n];

		foreach(ref element; this._data)
		{
			auto tmp = Foo(1);
			element = tmp;
		}
	}
}

void main(string[] args)
{
	auto bar = Bar(1);
}

On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote:
> In the following code, the `_foo` pointer (of the Foo struct) is null in the first call to the destructor. Why is this? I think it's got something to do with the foreach loop but I'm not sure. Any ideas?
>
> struct Bar
> {
> 	private Foo[] _data;
>
> 	public this(int n)
> 	{
> 		this._data = (cast(Foo*) calloc(n, Foo.sizeof))[0 .. n];
>
> 		foreach(ref element; this._data)
> 		{
> 			auto tmp = Foo(1);
> 			element = tmp;
> 		}
> 	}
> }

Because `element = tmp` destroys `element`, which you allocated filled with zeroes.
The destructor will run for each `element`.

On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote:
> In the following code, the `_foo` pointer (of the Foo struct) is null in the first call to the destructor. Why is this? I think it's got something to do with the foreach loop but I'm not sure. Any ideas?

Oof. Dangerous stuff. As Moritz pointed out, default opAssign will call the destructor on Foo. I should, however, elaborate further. You're dealing with uninitialized data. calloc() gives you zero-initialized block, which is not necessarily how Foo.init would look (it does in this case, but that's not true in general case).
malloc() gives you a potentially garbage-filled block, which is even more dangerous.

When filling an array of uninitialized values, use std.algorithm.moveEmplace(src, dst) instead of assignment. And, if you have destructors, you have to call the destructors manually when you free the array.
Furthermore, since Bar._data is an array of Foos, and Foo has a pointer in it, you might want to register the Bar._data array with the GC (GC.addRange, GC.removeRange). Unless you're willing to manually make sure that GC *never* sees those pointers.

On Saturday, 20 May 2017 at 11:15:57 UTC, Moritz Maxeiner wrote:
> Because `element = tmp` destroys `element`, which you allocated filled with zeroes.
> The destructor will run for each `element`.

Right, I get it because the destructors running on the struct that is being replaced. Doh!

On Saturday, 20 May 2017 at 12:25:39 UTC, Stanislav Blinov wrote:
> Oof. Dangerous stuff.

:)

Thanks for the heads up but I think I'm covering all cases in my main code.

On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote:
Looks like you would want to use emplace [0] here.

> 	public this(int n)
> 	{
> 		this._data = (cast(Foo*) calloc(n, Foo.sizeof))[0 .. n];
>
> 		foreach(ref element; this._data)
> 		{
> 			auto tmp = Foo(1);
> 			element = tmp;
> 		}
> 	}

Cheers,
Eduard

[0] - https://dlang.org/phobos/std_conv.html#.emplace.3

On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote:
> 		// Why is this._foo null here???

The others have answered why and what to do, but note that according to the spec, that any struct should be able to have its destructor called, so you should do a null check in there anyway.

On Sunday, 21 May 2017 at 12:48:10 UTC, Adam D. Ruppe wrote:
> On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote:
>> 		// Why is this._foo null here???
>
> The others have answered why and what to do, but note that according to the spec, that any struct should be able to have its destructor called, so you should do a null check in there anyway.

Not if you either emplace() or blit Foo.init into all of the array elements.

On Sunday, 21 May 2017 at 12:48:10 UTC, Adam D. Ruppe wrote:
> Any struct should be able to have its destructor called

Does this rule also applies to class objects?

On Sunday, 21 May 2017 at 23:59:08 UTC, Guillaume Piolat wrote:
> On Sunday, 21 May 2017 at 12:48:10 UTC, Adam D. Ruppe wrote:
>> Any struct should be able to have its destructor called
>
> Does this rule also applies to class objects?

Yes. If your destructor does modify the state, you should expect it to be called and have the state ready for it.

When you're using the GC, destructors *may* not be called under certain conditions:

http://dlang.org/spec/class.html#destructors

But there's no stopping you from destructing manually (via destroy() call), or by allocating classes manually via malloc or on the stack.