Disclaimer: I'm just discussing the singleton patern per se. I haven't read the documentation of Boost.Singleton nor I can comment on its design. I'm not voting for nor aganist the library. On Jan 16, 2008 12:05 PM, Tobias Schwinger <tschwinger@isonews2.com> wrote:
Giovanni Piero Deretta wrote:
On Jan 16, 2008 9:07 AM, Tobias Schwinger <tschwinger@isonews2.com> wrote:
Giovanni Piero Deretta wrote:
[...] 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."
Hum, the difference between "structured programming" and goto-based programming is well known and I didn't feel the need to define it. (but if you really want to: http://en.wikipedia.org/wiki/Structured_programming) What is not obvious (to me at least) is how singletons are more structured (in the sense of 'data structure') than a global object.
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."
How *hardware* I/O registers have anything to do with software engineering best practices?
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. [...]
The problem is that most of these points just make globals more usable, do not really address the problem with globals: an implicitly shared resource. In particular:
1.2. embraces a design that can easily be changed to use non-globally scoped objects instead, and
How? Or you design upfront not to rely on a non global scoped object, passing around a state pointer and not assuming global visibility of changes or you don't.
3.1. allows to properly model unique facilities (hardware, registries, etc.) in an object oriented fashion, and
I do not think you can usefully provide an OO interface to hardware registers, and anyways what is unique in one release of your hardware might not be in the next one. There might be higher level abstractions that are best modelled as singletons. The point is, are these common enough that they deserve a generic solution? -- gpd