Question on JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR


#1

I have a class which inherits AudioSource.
From looking at a class from the Juce API which also inherits AudioSource I see that it uses a macro in the private section of the header.

JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (classname);

where classname is the name of the class.

Do I need this?
If so, I really don’t know how do it. I have a problem with the namespace here, in particular using the namespace together with macros.
Wrapping the definitions of my class in
BEGIN_JUCE_NAMESPACE
END_JUCE_NAMESPACE
is not an option.

I tried this
juce::JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (classname);

but, no luck, I guess this does not work because JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR is a macro.

Can someone please help with this?
Cheers


#2

Don’t ever use the BEGIN_JUCE_NAMESPACE macros in your code. In fact, I should probably undef them so that you can’t…

If you’re a leaky programmer, then you probably do.

Sorry, I guess I should have used an explicit namespace in the macro, e.g.


#3

Many thanks for the help.

So, I put this in the private section of the declaration of my class, right?

JUCE_NAMESPACE::LeakedObjectDetector<myclass> JUCE_JOIN_MACRO (leakDetector, __LINE__);

And, should I do a similar thing for the “NON_COPYABLE part” of
JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR
? I mean, the macro is somehow combining 2 macros.
(From the documentation:


#4

Easiest thing would just be to fix that definition in the juce codebase and use the macro normally, rather than typing out the whole thing in your own code. I’ll update it next time I do a check-in anyway.


#5

I’m asking because I don’t want to risk to redefine the defined macro by doing this

But, thanks a lot, I guess it works so far.
Cheers


#6

eh? Don’t redefine it in your code, just fix the original version of it - I’m going to fix it anyway, so in the meantime you could just patch your copy so you can use it.