Jason Hise wrote:

I have a question about the longevity lifetime. Does such a lifetime only manage destruction order, or should it also manage order of creation? The way I'm currently implementing my longevity lifetime policy, there would be a master function in the LongevityManagerSingleton which would set the 'creation level'. This would basically create singletons up to this level or destroy them down to this level, so that all singletons at a given level could be assured that singletons with a smaller longevity number existed for their entire lifetime. Example:

A has longevity 0, B = 1, C = 2, D = 3, E = 4

Upon setting the creation level to 3, A would be created, then B, then C, then D. Subsequently setting the creation level to 1 would destroy D, then destroy C.

Is this anything like what the users of a longevity lifetime would like, or am I completely off track here?

I would have normally expected singleton creation to be handled with a lazy creation policy. This means that they are not created until used, and if not used never created. Then destruction would take place with the standard destruction policy. If you want to force creation at an earlier stage in the program execution then just call GetInstance() and throw away the result. BTW, regarding your concerns on integrating with say boost.thread, why not place all dependencies under a pre-processor guard, that enables threading. Then if you want to enable threading, you would set the pre-processor guard (like the smart pointers implementations), but also include the correct policy in your template specification. This means that under those circumstances where you want both threaded and un-threaded singletons, you can achieve this by turning on the boost directive, and using the policies accordingly. Without the pre-processor directive you simply would not have access to the multi-threaded policies. Dave