"Right way" for ofApp to have ofColor member?

I went from this implementation of my ofApp.cpp (aka testApp.cpp):

  
  
#include "ofApp.h"  
  
const ofColor bgColor(33, 33, 33);  
  
void ofApp::setup() {  
	ofBackground(bgColor);  
}  
  

To this:

  
  
#pragma once  
#include "ofMain.h"  
  
class ofApp : public ofBaseApp {  
  
	public:  
		ofApp() : bgColor(ofColor(33, 33, 33)) {};  
		void setup();  
		// ...  
		void gotMessage(ofMessage msg);  
  
    private:  
		const ofColor bgColor;  
  
};  
  
  

I simply moved the global declaration of bgColor out of testApp.cpp and into testApp.h and added a constructor with an initialization list to initialize bgColor.

Is the latter the “right way” to do such a thing? (I’m having a hard time drawing the line between C++ practices and what is acceptable with the styles of various OF testApp implementations I’ve seen.)

Is it better to declare members in testApp.h and use an initialization list, rather than declare globals at the top of testApp.cpp ?

“Better” depends on a lot of things. Some of the functionality of an OF application isn’t available in the constructor yet, so loading images or other assets is best done in setup(), that’s why people sometimes use static members or having pointers that can be allocated in setup(). Generally it’s better to have data objects be members of a class rather than floating around, so for an object that doesn’t have an initialize method of some kind (setup or whatever) the initialization list on the constructor is a good idea. I think the hesitance to use initialization lists is just a left over from when OF was generally done in a more C-style approach, but there’s also very few times in an ofApp where you’re going to need to have a resource or data member available at construction time. On objects that are going to be members of an app, it’s really handy and quite common. That’s not a very thorough answer, but hopefully it helps clear things up a little bit.

Thanks Joshua. I’ve further refactored my testApp, removing “globals” and making them testApp members.

Also, per your previous post, I understand a little more about the lifecycle of testApp and agree w/ what you’re saying w/r/t using setup to delegate certain initialization of my own objects.

Now if I could only brush up on my trig knowledge…