• Atila Neves (14/14) Dec 16 2016 So you decide to use std.experimental.allocator for your memory
• Basile B. (4/19) Dec 16 2016 Just for those who don't know it yet, Druntime always leaks 88

Atila Neves <atila.neves gmail.com> writes:

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

Basile B. <b2.temp gmx.com> writes:

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