"#define private public" - Neat little trick to access private members

#1

I had a class inside a class inside a class (all private members) whose variable I wanted to access easily for debugging reasons, with minimal modification to the code.

I found a really easy way to access the variable from my main function simply by using a preprocessor declaration that turns all privates public :wink:

Then from main I was able to access it with class.class.class.variable

1 Like
#2

Ouch, that’s horrible. :smiley:

Just add a getter method for the variable or make it explicitly public.

2 Likes
#3

But I would have to create a getter method for every class it sits inside too, right?

#4

There are probably better ways to debug than hacking private members to be accessible from an outer scope. Like using the debugger or putting jasserts or logging in the inner classes implementations…

3 Likes
#5

Well, if encapsulation is optional, why not writing C?

I am still undecided, if I call that bad practise or sabotage…

#6

Can I burn this thread for its title?

You really have to ask yourself what in the hell you’re trying to do if you need to do something so drastic, and borderline insane!

#7

This looks and smells bad…
Not to mention this is very likely compiler and OS dependent behaviour…

#8

You’re a wild-man!

1 Like
#9

Lol. I appreciate the concern everyone but relax, no one is suggesting this go into any release build.

I just wanted to know what it would sound like If I modulated a certain variable and before doing it the “right” way I wanted to test it out quick and dirty.

I have removed the the preprocessor directive already. Balance has been restored to the universe :slight_smile:

1 Like
#10

:joy:

2 Likes
#11

Hijacking the post (but with some correlation to the class calls):

I’ve a FileLoader class that uses it’s own thread to load a file and then giving a pointer to the AudioBuffer it’s stored. Since I’ll be using that AudioBuffer to be read in an oscillator in a Synth with multiple voices, I’d like to call it only once in the AudioProcessor and pass it to the Oscillator (AudioProcessor->Synth->Voice->Oscillator), otherwise loading the file in the Osc itself (which would avoid a lot of passing mess) is really inefficient since it will create a background thread + load the same file for each voice.
But making setters from the processor to the oscillator seems kinda dirty somehow.

Which would be the neatest way to pass the buffer pointer to the Osc? Or I’m just overcomplicating this and can be made in a simpler way?

#12

Rather than setting… getting?

So from wherever FileLoader is called, also create a getAudioBufferPointer function, then from the Oscillator class call getAudioBuferPointer()?

#13

While you are at it, this one is also really neat:
#define true (rand() > 0.01)

5 Likes
#14

Handy way to catch use of those pesky “auto” variables, at runtime :

#define auto std::cout << "damn auto!\n"; auto
7 Likes
#15

Love these suggestions! How about this?

4 Likes