Splitting Main.cpp into Application.h to allow including in Components

General JUCE discussion
1

I'm restructuring my app to allow Components and other classes to access objects via shared pointers in my main JUCEApplication. I've taken inspiration from Introjucer, however, run into some difficulties with circular header includes.

So I split up the main part of Main.cpp into Application.h similar to how its done in Introjucer. So I could then include it in the Components and classes where I want to access the shared objects. This is all good - however, I need to include MainComponent in Application.h. And in MainComponent.h I need to include Application.h so that (in this case) I can access the app settings via shared pointer to PropertiesFile.

I tried using forward declarations but I need to declare functions to access the private shared pointers, but I need function declarations too so might as well use a seperate header file.

My next step will be to split out Application.h into cpp and header file, or a stripped down header just for includes in Components... but not sure how best to deal with the inner MainWindow class.

I'm wondering if I'm overcomplicating things here or if I'm going down the right track or not.

 

Thanks

2

That's a slightly complicated explanation.  And I had a peek at Introjucer to see what you were getting at. 

There might be a simpler way, but I'll tell you how I manage this problem: 

Use a common class CommonObjects which has references to shared objects. something like:

class CommonObjects {

public:

CommonObjects(SharedA & a, SharedB & b) : a(a), b(b) {}

A & a;

B & b; 

};

I initialize it in a main application class and pass it as a constructor parameter to anything that's going to need all those objects. 

If A or B needed CommonObjects I'd have to use a .cpp/.h file split and potentially a forward class declaration.  But generally everything seems to work out just fine with this scheme.

You could also look at SharedResourcePointer<> as a completely different approach that might be useful under some circumstances.

3

Thanks, that makes a lot of sense - previously I was using ReferenceCountedObjects and passing pointers to classes that needed them but it was beginning to get unwieldy… Wrapping them all in one seperate class seems like a neat approach.