Giovanni Piero Deretta wrote:
On Jan 16, 2008 9:07 AM, Tobias Schwinger <tschwinger@isonews2.com> wrote:
Giovanni Piero Deretta wrote:
On Jan 15, 2008 12:21 PM, Anthony Williams <anthony_w.geo@yahoo.com> wrote:
John Torjo <john.groups <at> torjo.com> writes:
Today starts the formal Fast-Track review of the Boost.Utility/Singleton library. This is a very useful utility, so I'm expecting lots of reviews ;) * What is your evaluation of the potential usefulness of the library? I don't think this is at all useful. People should not be encouraged to use singletons, as there is already a tendency towards overuse. In most circumstances, singletons are a poor design choice, so there is little requirement for their use. I consider singletons just another form of globals and thus bad style. Let's see:
"I consider if, else, for, do, while and the ternary operator just another form of goto and therefore bad style."
;-)
Except that 'if', 'else' and friends are a *restricted* form of goto (i.e. the 'structured' in structured programming) and are thus acceptable.
Let's see: "Singletons are 'structured' globals (i.e. the 'structure' in 'data structure') and are thus acceptable." ;-) Some more fun: "I/O registers are global and thus bad style, so I built a computer without. Still trying to telepathically use that thing, though." ;-)
In general, a singleton hardly adds any restriction to global (except from being thread safe). :)
Thread-safety is just a bonbon here: So let's take another look at the key responsibilities of a Singleton is for: 1. Making the user implement a class 1.1. encourages a well-defined object interface, 1.2. embraces a design that can easily be changed to use non-globally scoped objects instead, and 1.3. prevents pollution of the global namespace. 2. Providing on-demand initialization 2.1. makes non-trivial construction work with any ABI's shared libs, and 2.2. automatically resolves dependencies between Singletons. 3. Ensuring a single instance of the Singleton class 3.1. allows to properly model unique facilities (hardware, registries, etc.) in an object oriented fashion, and 3.2. allows to encapsulate a well-defined access point in the first place. Note that the need for 2.1. makes 1. even more important as you're limited to trivially constructible types writing a shared library that is supposed to work portably. OK, that's about it. I might have forgotten something, but I'm in a bit of a hurry, right now. Sorry. Regards, Tobias