Closed thomasdenney closed 5 years ago
Hi @thomasdenney
Thanks for your contribution here.
To address this issue and other related issues, we've made the microbit heap allocator more transparent in the beta version of microbit-dal 2.1.0, so that it no longer relies on function level overloads to intercept memory allocations. We now fully replace the libc heap allocator.
I'm 99.99% sure that this means that the issue behind this PR will be fixed by this, so if you're happy with this, I'd like to close off this PR?
Relevant patch is here, if you'd like to review it: https://github.com/lancaster-university/microbit-dal/commit/0c746140a3506c2a1991b4789cb0edbcb19cd97d
p.s. Apologies for leaving this PR hanging so long.
Looks good to me. Is it still the case that you have to include the relevant header, or will this be the default allocator regardless?
That's correct, you no longer need to include the header. The MicroBitHeapAllocator will be used by default.
You can disable this and return to using the libc allocator via a compile time CONFIG option, if you so desire, but would lose the ability to have multiple heap regions and safety in interrupt contexts.
Exactly the same as
delete
(in the same way thatnew
is the same asnew[]
) but ensures correct C++ semantics.Resolves https://github.com/lancaster-university/microbit-dal/issues/348