|
Boost : |
Subject: Re: [boost] Review Request: Singularity
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-08-25 08:56:25
Mathias Gaunard wrote:
> On 24/08/2011 15:29, Alexey Tkachenko wrote:
> > On 24-Aug-2011, at 9:18 PM, Mathias Gaunard wrote:
> >> On 24/08/2011 04:28, Ben Robinson wrote:
>
> >>> 1) You have little control over when the Singleton is
> >>> destroyed. Should you have multiple Singleton which
> >>> depend on each-other, very often you need a very
> >>> specific teardown order.
> >>
> >> It should be the inverse order of the construction order.
> >
> > Consider dependency between singletons
>
> Your point being?
>
> Construct your singletons in the order required by your
> dependency, then let destruction happen in the inverse order.
>
> function-level statics are constructed *on the first call of
> the function*, not in an unspecified order like class-level
> statics or global variables.
If an application has a logging Singleton and each of the other Singletons in that application used the logging Singleton in its destructor, but one or more of those other Singletons were created before the logging Singleton, you'd have a problem.
This is the destruction order problem which leads to so many different partial solutions, such as allowing the logging Singleton to be implemented as a function local static pointer and left to leak.
When you know that a particular Singleton is needed after all others, you might try to create it early, but if there are objects with static storage duration that access any of the Singletons, then you lose control over the initialization order.
_____
Rob Stewart robert.stewart_at_[hidden]
Software Engineer using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP http://www.sig.com
________________________________
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk