If you really want to be sure that you don’t have a duplicate counter somehow, you can substitute this implementation of the Juce leak detector (requires typeid in the compiler). It’s a little CRTP hack (Curiously Recurring Template Pattern).
// Derived classes are automatically leak-checked on exit
template <class OwnerClass>
class LeakChecked : private JUCE_NAMESPACE::LeakedObjectDetector <LeakChecked <OwnerClass> >
{
private:
friend class JUCE_NAMESPACE::LeakedObjectDetector <LeakChecked>;
static const char* getLeakedObjectClassName() throw()
{ return typeid (OwnerClass).name (); }
};
Note that this implementation of LeakChecked can co-exist with the Juce version. In other words you can have both leak detectors installed in your object as a safeguard and also, perhaps if they behave differently it will expose an underlying issue?
Usage example:
class MyObject : public LeakChecked <MyObject>
{
private:
JUCE_LEAK_DETECTOR (MyObject); // Optional
};
Do you have objects with static storage duration at file scope? I.e. global variables with constructors? Perhaps you are having some order of initialization issues, my hobgoblin du jour.
I did and guess what? Nothing is reported, however, also no more dangling deletions and leak warnings! Heck. This compiler/linker/project is completely undeterministic. That’s a nightmare.
Not in the source code, but obviously in how it is compiled and linked, that is, possibly in the project settings? These duplicate instances should never happen. It is impossible to rely on the library, if it is that easy to get your binary corrupted without noticing. That’s what worries me a lot more than a leak detector.
Your LeakChecked class is fine, but I rather want to see the internal Juce implementation fixed.
Singletons? Sure. I’m using the proposed Juce singleton scheme, though. Otherwise, no.
Ah, and btw, I’m not wearing a helmet. I have a geiger counter next to me so I can stop when the binary gets above 0.8 Microsievert/hour
You do realize that the LeakChecked template is just a wrapper around the Juce leak checker?
All I can think of is try using a StaticCriticalSection to protect the pointer inside the call to getInstance(). You might have to change juce_DeclareSingleton and juce_ImplementSingleton to do that, or you could just write your own getInstance().
Thanks for your reponse and sorry for my late reply.
Absolutely.
I’m not having so much concerns with the leak detector. I can live with a few false positives (btw: they went away with the latest tip 60 ). What really worries me is that the linker is doing such nasty things like creating duplicate instances without any notice. It is beyond me how the developer community can live with that.
No, there’s nothing wrong with the linker. If all your modules use identical copies of a class, then its statics will only appear once. But if you have two cpp files that include juce.h with slightly different settings, and some of the classes end up taking slightly forms because of that, then the linker will treat them as a different classes, and give them separate copies of their static data.
How do I know? All my modules include “JuceHeader.h”. This inlcudes juce_amalgamated.h. I don’t know why there are still “JuceLibraryCode1.mm” through “…4.mm”, but the project doesn’t compile without them.
