I have worked with Juce for many years, and I’m a proposnenet if the framework.
That being said, I have recenting been trying to see if I can use Juse to create a cross-platworm GUI test app for a cross-platform software framework that my company has created. In my initial investigation, it seemed like it would meet our needs, but I recently ran into a problem…
In Juce framework (and sodtware that is developed from it), there is extensive use of the Juce internal shared object pointer class (“juce::SharedResourcePointer“). Normally, when I create software for the Juce framework, I just use that class to declare shared objects.
In the software framework that my company has created, we make entensive use of “std::shared_ptr”. It seems in my development that these two do not co-exist well.
The prototype of the test GUI that I created has the UI written entirely using Juce, and it calls shared libararies (Windows DLLs, Linux SOs, …). When compiled for “debug”, as the software initializes, I start getting DEBUG asserts for the Juce Heap Debugging code.
This does not happen in the release build. It also does not happen when I build the GUI test app code by itself or our internal framework by itself. The problem only happenes when I try to connect the two.
Does anyone know how to resolve this issue?
If not, does anyone know how to disable to Juce Heap Debugging functionality in a debug build of the code? It makse doing a debug session very difficult.
juce::SharedResourcePointer is not the same type of thing as std::shared_ptr. Chances are, you might be confusing them.
juce::SharedResourcePointer is not a normal shared pointer which you can assign to and reset. Instead, it wraps a static instance of a resource, so for example if you have multiple instances of juce::SharedResourcePointer<MyClass>, you can be sure that they all point to the same instance of MyClass. It’s basically intended as an alternative to creating singletons (like using static MyClass singleton;).
For regular smart pointers, you should probably be using std::unique_ptr and std::shared_ptr, and not anything in the Juce library. (This goes for Juce objects themselves also–storing them in std::unique_ptr and std::shared_ptr works very well).
Juce does have juce::ReferenceCountedObject as an equivalent of std::shared_ptr, but std::shared_ptr is generally preferable. The only exception here is when you need to store a shared resource in a juce::var, in which case you can only do it with juce::ReferenceCountedObject::Ptr. (Juce also has juce::ReferenceCountedArray, but in most cases, std::vector<std::shared_ptr<>> is a better fit than this.)
If the problem seems to go away in release, chances are you simply don’t see them, because jasserts are silent in release builds.
std::shared_ptrs are fine, I use them as well. But I would recommend, not to use it as default pointer type, since it makes it hard to reason about lifetime and you can get memory leaks from two shared_ptrs referencing each other.
