digitalmars.D.announce - test_allocator v0.0.1 - don't leak memory in your
- 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
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
Dec 16 2016
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. AtilaJust for those who don't know it yet, Druntime always leaks 88 bytes: https://github.com/dlang/druntime/pull/1557
Dec 16 2016