Subject: Re: [boost] [Boost.utility]
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-01-26 16:05:30
> Take your best singleton class, but remove the bit where it
> intrudes and forces only a single instantiation. Call this
> "global", which provides the same thing as a singleton but
> allows other instantiations of the class.
OK, so it implicitly instantiates the object on first access, but the instance must be visible to any code interested in using it, right?
> My argument was that this class is more worth boost's time
> than the singleton class. The reason being, users of global
> could always re-introduce the single-instantiation behavior,
> but don't have to. This provides more flexibility.
Making a Singleton from a "global" implies somehow enforcing a single instance. Without help from the library, mistakes will happen. Indeed, if a UDT can be adorned in such a way as to prevent its use with anything but the Singleton library, user mistakes can be prevented by design.
I'd argue that one is a policy away from the other and that both are useful.
Rob Stewart robert.stewart_at_[hidden]
Software Engineer, Core Software using std::disclaimer;
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