Quote Originally Posted by kempofighter
I think that I have seen what the OP is talking about. I have seen a pattern where all data members of the class are static. Even though you can create multiple instances, every instances reads and writes to the same class attributes, which are all static.
Heheh, I decided to check my copy of the GoF book, and yeah, that pattern is listed as one of the things that the singleton pattern can replace (and conversely, the singleton pattern is one of those things that that pattern can replace).

Quote Originally Posted by kempofighter
If you have a type with a public constructor and you just create a static instance, there is nothing being enforced that would allow you to call that pattern a real implementation of singleton.
Yes, though I'd say that you can still refer to that lone object as a singleton, literally speaking.

Quote Originally Posted by Speedo
What get me is, you poll programmers about global state, and most will say it's a bad thing. Poll them again about singletons, and most tend to say that they're good. What's the difference?
I would say that "most tend to say that they're good" is an exaggeration, but my take is that the difference is because in those specific cases where one really needs to enforce the singleton property and a single point of access makes sense, the singleton pattern is tolerable (but woe to you if your requirements change too much!), whereas ordinary global variables give you global state with no mitigating factors (other than allowing you to be careless about design).