Subject: Re: [boost] [Boost.utility]
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-01-26 14:48:51
> Stewart, Robert wrote:
> > More than one instance can lead to unwanted contention, failed
> > synchronization, resource overallocation, etc. If one
> > assumes a single instance, those things are easier to manage.
> I still disagree with this. Just, don't type
> "some_expensive_resource r;".
That's easier said than done. There are many developers writing code that do whatever works. If the class permits creating multiple instances, they'll do regardless of whether it's good for them. If the class prevents being used in other than the prescribed manner, then they can't do the wrong thing.
> The programmer should be using a global access point. But
> even if we don't get past that:
> It doesn't require we have a singleton class. Imagine the
> global class I proposed existed. Just take your class and
> intrude it yourself, making it a singleton. Ta-da!
I'm not sure what semantics you're suggesting for your class. If you described them, I missed it. I'll assume, however, that you're suggested that all instances of global<T> refer to the same instance of T.
> Singleton -> Always intrusive
> Global -> Not always instruive , can be
> I think it's clear which is generally more useful.
I think it's clear that both have their uses.
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