I just came across the following macro in the latest example audio plugin code:
JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR
Can someone explain what this is doing? In semi-layman terms? I was an anthro major in college. I’m pretty decent at audio algorithms, but some of the nuances of C++ are lost on me.
I have been struggling with some weird audio bugs in my latest plugin, that are inconsistent. Which is my least favorite type of bug. Every now and then, the plugin seems to have some weird feedback when initialized, or some possible comb filtering, which makes me wonder if my optimization settings are generating multiple instances of the underlying audio processing block. Which would be totally weird, but the behavior is totally weird. So I’m wondering if the JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR would help with this.
The noncopyable part declares the copy constructor and operator= (must be in a private section to work). If you then (implicitly) copy an object an error is generated. The leak detector part adds the class to the Juce leak detector, e.g. if the class leaks an assertion is triggered. The latter part is magic for me as well.
Not sure if this helps in your case as this sounds to occure only in release builds.
A good rule of thumb is that if it’s possible to add that macro to a class (i.e. if the class doesn’t use copy-by-value semantics), then you should do so. Having it there can save you from a few subtle C++ blunders, as well as catching leaks.
The diamond problem is not applicable here though surely? Since all the ambiguous members are doing is hiding methods that you explicitly don’t want called, I’m not sure how that creates any issues that aren’t present in almost any MI pattern. Those methods will never need to be disambiguated, and neither AFAICT do the shared parent classes since they should be empty[1] except for the private method declarations.
[1] I’ve not actually looked at TheVinn’s code here.
That’s right - but for LeakChecked<> only, afaict, since it’s a template. According to the example Bruce gave; if a derived class inherits a base class (where the base inherits Uncopyable), and this derived class also inherits Uncopyable, that would cause diamond inheritance. That’s why using a macro is simple copy pasta - less thought involved.
That’s right - but for LeakChecked<> only, afaict, since it’s a template. According to the example Bruce gave; if a derived class inherits a base class (where the base inherits Uncopyable), and this derived class also inherits Uncopyable, that would cause diamond inheritance. That’s why using a macro is simple copy pasta - less thought involved.[/quote]
Right. But juce style dictates that the base class should be minimal and not instantiable and wouldn’t inherit Uncopyable. The concrete final class would.
