In my app I have a few objects that have to be constructed before main() is entered, and some of them are interdependent on each other. I’m sure you see the obvious problem with that.
My solution starts with using the “StaticObject” template I wrote about previously which solves order-of-construction issues with synchronization primitives used to protect singletons.
Using the StaticObject, I wrote a “SharedSingleton” template class that acts as a ReferenceCountedObject. The template provides a static method getInstance() which returns a ReferenceCountedObjectPtr to the singleton, creating the singleton if it hasn’t been created. The creation of the singleton uses the thread-safe mechanism I wrote about here:
I use a SpinLock instead of a CriticalSection because SpinLock doesn’t need to be destroyed, this avoids order of destruction issues on exit.
So, to address your original problem, with this model if you wanted to get rid of the manual initializer for the juce Gui, just shove it into a reference counted singleton that has a thread-safe getInstance () immune to order of initialization issues (using the StaticObject technique), and have top level objects like JUCEApplication acquire and hold a reference. When the last dependent object is destroyed, the reference to the singleton will go away and things will clean themselves up lovely.