This interesting to me. Sometime ago, I needed a singleton for an aspect of the serialization library. It looked like boost was going to have one but finally it didn't. I crafted one that seems very similar in concept to the one described by memory pool documentation. At the time I didn't realize that there was such a solution already in boost. It would seem that all these solutions would suffer from the same problem. It would also seem that the this (and some other "surprises" would be eliminated if one could assume that static global object would be destroyed in the reverse order of their construction. It seems that this always happens - but it's not guarenteed.
Actually I think it should be guarenteed, but I can't find the relevant text at present :-(
Perhaps the thing to look at is thread_specific_ptr. Maybe it should get destroyed sooner if it's created later. Maybe a wrapper can be crafted for those late initialization - late destruction objects.
To clarify the issue is: * Global object is constructed "early". * Main starts. * Global object first references singleton_pool at this point - so singleton_pool gets constructed "late". * main exits. * singleton pool is cleaned up first (because it was the last to be constructed). * Global object is cleaned up.... oops, it's still referencing the pool. So it's the sort of issue that only a garbage collector can solve - albeit we're looking at coded reference-counted collectors. Cheers, John.