----- Original Message ----- From: "Mithun R K" <mithun.radhakrishnan@hp.com> To: <boost@lists.boost.org> Sent: Friday, January 14, 2005 4:34 AM Subject: RE: [boost] Singleton (with Singleton Registry: Clarification)
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.
No, you explained it fine. Its the direction and associated ramifications that I was making observations on. Poorly :-)
<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?
The "typical problem" is that objects in any substantial application want to be destroyed in a runtime-dependent order. The exact order is driven by what activity occurs during execution. Trying to dictate an order (i.e. longevity-int) onto something that is dynamic is... misdirected. What I am describing here can equally be applied to the default order of dtor imposed by the C runtime (CRT order). Whether the imposed, *fixed* order is CRT or longevity-int it will eventually be the wrong order for some execution path of your application. longevity-int prioritizing may reduce the ordering problem, I cant really say. But it would certainly be a significant thing to implement and maintain. With all that effort, there could be disappointment when an application still crashes on termination. ps: By CRT I mean the order of dtor of global objects imposed by the C runtime.
<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.
Its the pre-determined order that is the problem.
With the above, I (hoped to) achieve a predetermined order of destruction
of
static singletons, even if the ctor-sequence is runtime-dependent...
Again; you do not know the required order of destruction at compile-time.
<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.
No worries Mithun. If I havent successfully made my point now then its probably best to just carry on. My observations come from several attempts to impose strategies onto dtor-ordering (and also ctor-ordering). These experiences have been fairly humbling. My favorite technique these days involves something that is known as "function guards" (as per the link provided previously) and "custom dependency work" (hacking). important_object & object1() { static important_object *p = new important_object; return *p; } // Hack example; forces instantiation during CSV static important_object &r = object1(); Cheers, Scott