So you decide to use std.experimental.allocator for your memory allocations. Let's say you're as paranoid as me about getting the allocations right. How do you know you're not leaking memory now (no GC safety net)?. Or worse, deallocating memory you shouldn't? The program didn't crash, but you never do know...

Enter the test allocator here:

http://code.dlang.org/packages/test_allocator

Run your code through that little guy in a unittest build and worry no more. It throws an AssertError in the destructor if there's a memory leak and also if you try and deallocate memory that it doesn't know about. It's backed by Mallocator because then you can also use valgrind or address sanitizer to catch even more bugs.

Atila

On Friday, 16 December 2016 at 21:03:11 UTC, Atila Neves wrote:
> So you decide to use std.experimental.allocator for your memory allocations. Let's say you're as paranoid as me about getting the allocations right. How do you know you're not leaking memory now (no GC safety net)?. Or worse, deallocating memory you shouldn't? The program didn't crash, but you never do know...
>
> Enter the test allocator here:
>
> http://code.dlang.org/packages/test_allocator
>
> Run your code through that little guy in a unittest build and worry no more. It throws an AssertError in the destructor if there's a memory leak and also if you try and deallocate memory that it doesn't know about. It's backed by Mallocator because then you can also use valgrind or address sanitizer to catch even more bugs.
>
> Atila

Just for those who don't know it yet, Druntime always leaks 88 bytes:
https://github.com/dlang/druntime/pull/1557