December 16, 2016 test_allocator v0.0.1 - don't leak memory in your std.experimental.allocator using code | ||||
---|---|---|---|---|
| ||||
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 |
December 16, 2016 Re: test_allocator v0.0.1 - don't leak memory in your std.experimental.allocator using code | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | 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 |
Copyright © 1999-2021 by the D Language Foundation