Dynamic array leak?
bitwise via Digitalmars-d
digitalmars-d at puremagic.com
Sat Aug 12 10:25:36 PDT 2017
On Saturday, 12 August 2017 at 08:16:56 UTC, Temtaime wrote:
>
> Collect - is a hint to the GC, not an order. It can ignore this
> request.
If this is the case, then D's GC should have an option to force
collection like C#'s GC:
https://msdn.microsoft.com/en-us/library/bb495757(v=vs.110).aspx
> Also do not rely on the gc calling a dtor - it is not safe and
> can be called totally randomed, so use RC instead or expicit
> destroy()
RC is not applicable. I'm doing unit tests for a non-GC container
and trying to make sure all destructors are called properly.
Example:
unittest {
auto a = List!int([S(0), S(1), S(2)]);
a.popBack();
assert(equal(a[], [S(0), S(1)]));
}
// lots of similar unittests
unittest {
import std.stdio;
GC.collect();
assert(S.count == 0);
}
So if all goes well, S.count should be zero, but the arrays I'm
testing against are being allocated on the heap. Given the
conditions of the tests, it seems like GC.collect should be able
to reclaim those arrays after the unit tests have exited, and in
most cases does.
The ideal solution though, would be to allocate those arrays on
the stack and avoid the problem altogether. There doesn't seem to
be any reasonable way to do it though.
// won't this allocate anyways?
S[2] b = [S(0), S(1)];
assert(equal(a[], b[]));
// why can't I just declare a static array inline?
assert(equal(a[], int[2]{ S(0), S(1) }));
More information about the Digitalmars-d
mailing list