Hello, Scott/Jason/All. Thank you for having looked at this approach. Scott, I'm not entirely sure I've understood everything you've said... I apologise if I've not made my approach clear. I'm afraid I might have messed up in explaining it. <quote> While I can see where it is headed and can imagine that it will solve a set of problems, does it solve the typical problem? [snip] This is different to the CRT model... </quote> What does one mean by the "typical problem"? And by "the CRT model", do we refer to Jason's new code? <quote> The perfect ordering of global ctor+dtor is runtime dependent, i.e. the sequence of ctor's and dtor's alters from one execution to another. </quote> What I was aiming at was to destroy Singleton objects in a predetermined order, based on the longevity-ints specified, *regardless* of the order of construction. E.g. I'd like my Logger instance to be "alive" until all other Singleton instances are destroyed (because destructors log). I'd like this irrespective of when the first log-request was made (and the Logger was constructed). So I set the Logger's longevity-int to max. Here's how I postpone destruction. The Singleton constructor looks like: /*private*/ Singleton<T>::Singleton() : SingletonBase( Longevity ), T() { static SingletonUnregisterer unregisterer(this) ; // <------------- 1 SingletonRegistry::getInstance().registerSingleton( this ) ; // <-- 2 } /*static*/ T& Singleton<T>::getInstance() { static T* pInstance = new Singleton<T> ; return *pInstance ; } At Line#2, the SingletonRegistry gets a handle to the Singleton instance. Line#1 here is a hack. SingletonUnregisterer is a class whose dtor "unregisters" the Singleton from the SingletonRegistry. The dtor is triggered when the library unloads, or the app exits. Unregistration doesn't necessarily destroy the Singleton immediately. It merely marks the Singleton as ready for destruction. The object won't be destroyed (deleted) until all objects with lesser longevity are marked/destroyed. Since the Logger's longevity is max, it will be destroyed last (after all other Singletons have been destroyed, and all their destructors have finished logging). Similarly, the rest. Please comment? I read the article you pointed me to... With respect, shouldn't the above take care of de-initialization order? <quote> If your model is different to the "real" model (ctor+dtor sequence is runtime dependent), what will you achieve with it? </quote> With the above, I (hoped to) achieve a predetermined order of destruction of static singletons, even if the ctor-sequence is runtime-dependent... <quote> If someone wth a dtor dependency issue discovers your "longevity-int" feature, applies it to a complex codebase only to discover that the true problem is outside the domain of an "ordering ints" strategy, is the wasted effort entirely their fault? A ridiculous question posed to make a point. </quote> I'm really sorry, but I couldn't follow, again... I'm not sure whose fault it is if someone mistakes the "true problem" to be a singleton-deinitialization-problem, when it isn't... (Did I get that right?) I look forward to further comments. Many thanx, Mithun -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Scott Woods Sent: Thursday, January 13, 2005 6:46 AM To: boost@lists.boost.org Subject: Re: [boost] Singleton ----- Original Message ----- From: "Jason Hise" <chaos@ezequal.com> To: <boost@lists.boost.org> Sent: Wednesday, January 12, 2005 11:07 AM Subject: Re: [boost] Singleton [snip]
My approach was:
1. Have a single SingletonRegistry that would keep pointers to all Singleton instances (well, actually, SingletonBase instances. SingletonBase is not a class-template.) 2. Each instance has a longevity-int associated with it. At destruction-time, we sort the singleton-instances based on their relative longevities, and destroy the objects in order. It's kinda up to the "client" of Singleton<T> to figure out the collaboration between her classes, and assign longevity-values to her classes. 3. Singleton<T> instances are "registered" with the SingletonRegistry, by its constructor. 4. Singleton<T>::~Singleton() lets the registry know that the instance may be destroyed. The SingletonRegistry destroys the instance if all singletons with a lesser longevity have already been marked for destruction. (I guess that's simple mark-and-sweep.)
I'd be honoured and grateful if anyone has comments on this approach.
At your command :-) Apologies for the delayed response but I was waiting for this to develop. Instead it seems to have gone elsewhere. After struggling with the issue of ctor+dtor of C++ globals for some time, I wonder at the efficacy of your own intentions, WRT correct dtor of singletons. While I can see where it is headed and can imagine that it will solve a set of problems, does it solve the typical problem? Assigning some ordering "longevity-int" is creating another "model of destruction". This is different to the CRT model and more significantly, configurable. The perfect ordering of global ctor+dtor is runtime dependent, i.e. the sequence of ctor's and dtor's alters from one execution to another. Here's one instance of related research by others; http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.13 If your model is different to the "real" model (ctor+dtor sequence is runtime dependent), what will you achieve with it? If someone wth a dtor dependency issue discovers your "longevity-int" feature, applies it to a complex codebase only to discover that the true problem is outside the domain of an "ordering ints" strategy, is the wasted effort entirely their fault? A ridiculous question posed to make a point. Only hoping to reduce your workload. Developing the singleton template is starting to look like a real job. Cheers, Scott _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost