c++ - How to ensure Singleton is not destroyed prematurely? -

in project, i'm working 4 singletons made scott meyer's way. 1 of them:

levelrenderer& levelrenderer::instance() { static levelrenderer obj; return obj; } 

now 2 of singletons, levelrenderer , levelsymboltable interact each other. example, in method:

void levelrenderer::parse(std::vector<std::string>& lineset) { levelsymboltable& table = levelsymboltable::instance(); /** removed code irrelevant **/ // each line in lineset boost_foreach(std::string line, lineset) { // each character in line boost_foreach(char sym, line) { /** code... **/ // otherwise else { sf::sprite spr; // used levelsymboltable's instance here... table.generatespritefromsymbol(spr, sym); // ^ inside levelrenderer /** irrelevant code... **/ } } } } 

now, although problem hasn't occurred yet. thing afraid of is, if levelsymboltable instance destroyed before call generatespritefromsymbol ?

since used scott meyer way, singleton's instance allocated stack. hence is guaranteed destroyed using last created first destroyed rule. if levelsymboltable's instance created after levelrenderer's instance, destroyed before levelrenderer's instance, right? then, if call method of levelsymboltable inside levelrenderer (especially in levelrenderer's destructor), treading on undefined behaviour land.

as said before, problem hasn't occurred while debugging, , purely assumption , guess-work. so, conclusion correct? levelsymboltable liable destroyed before levelrenderer. if so, there way out of mess?

you don't have worry here.* static keyword guarantees available when initialized when program exits. so, can make call static variable @ point after has been initialized.

also, have reference levelsymboltable, not local variable. ampersand after class name means. can use locally, it's "referring to" true object exists somewhere else. so, when method exits, reference go out of scope object refers not.

*well, may have worry 1 thing. in destructor, should cleaning memory or file references or other things of nature have handle on. don't know why calling other objects in destructor.