|
Boost : |
Subject: Re: [boost] [Boost.utility]
From: GMan (gmannickg_at_[hidden])
Date: 2010-01-26 10:43:20
Ok, so what's the point of making it impossible to instantiate more than one
class? Yeah, I get it, you don't need more than one global service; so don't
make more than one instance. My argument is that you never truly need to
*stop* the instantiation of a class.
The global wrapper would merely provide every benefit you can think of in a
singleton, without the forceful and wasteful intrusion it has.
On Tue, Jan 26, 2010 at 7:14 AM, Frank Mori Hess <frank.hess_at_[hidden]>wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 26 January 2010, Mathias Gaunard wrote:
> > Andrew Chinkoff wrote:
> > >> Perhaps some boost::global<T> utility would be better, but a singleton
> > >> itself is bad practice, in my opinion. boost::global<T> would merely
> > >> create
> > >> a global access point to T:
> > >>
> > >> typedef boost::global<int> global_Int;
> > >> global_int.get() = 5; // getting the global int
> > >
> > > Perhaps you're right. It is a matter of taste.
> > > But I like to write "Object::Instance().get()" rather than
> > > "global_object.get()".
> >
> > One requires creating a new tailored object, the other adapts itself to
> > any object un-intrusively.
> >
> > So it's pretty obvious global<int>.get() is better, and not just a
> > matter of taste.
>
> One of the motivations for the singleton pattern is making it impossible to
> instantiate more than one instance of the class, which something which is
> unintrusive cannot accomplish. Maybe I'm missing something however, as I
> don't see the point of boost::global<T> at all?
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAktfBtsACgkQ5vihyNWuA4UYBQCeKxymd1XF8vzv9bANsit8PVzY
> FfsAoLgya2s7VtUpbSKw+3oT/d5NiNFa
> =Uv2d
> -----END PGP SIGNATURE-----
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
-- GMan, Nick Gorski
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk