Are thread AllocationHooks intended for JUCE internal use only?

I’m looking to implement some tests & run-time checks to verify my builds don’t allocate/deallocate on the audio thread.

JUCE already has some code to hook operator new/delete enabled by the JUCE_ENABLE_ALLOCATION_HOOKS define and it implements support for juce::UnitTest-based tests but it appears there’s no way for a consumer of JUCE to add a listener for a given thread as getAllocationHooksForThread() isn’t exposed in a header.

Is this correct, and is it intentional? It’s not a huge deal to reimplement a similar pattern in my own code, but I’d like to make sure I’m doing it for the right reasons.

Note that overriding new doesn’t catch all kinds of malloc calls, which is interesting especially if you work with third party dependencies that might use plain C under the hood.

We built an in-house audio thread allocation detector using system specific alloc hook apis and after some tweaking it now works quite well

1 Like