I currently have a case where some non-juce parts of our code base keeps a static shared pointer instance of some interface class.
The implementation will definetively clean up the held instance at shutdown, however when assigning a JUCE based implementation of that class here that contains types with the juce leak detector, this will cause false leak detector warnings at shutdown, since that static instance is deleted later than the JUCE shutdown routines run.
In this particular case, it’s a ReadWriteLock where the warning on shutdown is triggered through a WaitableEvent member in that lock instance. Silencing this warning requires a seemingly unnecessary rework resulting in potentially more complex implementation code to solve what is in fact a false alarm. I could define JUCE_CHECK_MEMORY_LEAKS to 0 in general but what I would prefer would be an option to bypass the checks on a per-instance base for cases like this. I’m not really sure how that would look like best, but I’d be interested in hearing thoughts from the JUCE team on this?
I’m not sure I can think of a good way to handle this especially if we’re talking about disabling leak detectors in the object and all it’s member variables recursively (maybe reflection might make this easier in the future?). Could you instead reset your shared pointer on shutdown?
I see the issue with possible nested member instances. One rather ugly solution could be a thread local flag set by some raii type that disables all leak detector instance created on the thread while that object exists on the stack, code example
std::shared_ptr<BaseClass> x;
{
juce::ScopedLeakDetectorDisabler dontInitLeakDetectors;
x = std::make_shared<ImplementationWithLeakDetecorMembers>();
}
// pass x to the non-juce interface
And yes, proper cleanup of the static instance would of course be the prefered solution, but the issue with shared pointers is that there still might be another instance somewhere holding up the ref count. Reworking it to a clear ownership pattern is possible and desirable in theory but would be a quite significant change in multiple projects depending on that implementation, which brings up other problems.
