|
Boost : |
From: Dave Handley (dave.handley_at_[hidden])
Date: 2005-01-14 10:36:44
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk