Why are you infected with Singletonitis?
Singletonitis, Part 2
Singletonitis, Part 3

Singletons and Memory Management
When to use and not to use singletons
Rate my engine!
learning singletons
Sharing data between game states
Good/Generic C++ Programming
Singleton managers
Singleton versus Monostate Pattern
The One: A Singleton Discussion (companion to article)
A Singleton Texture Manager for OpenGL (companion to article)

A Singleton Texture Manager for OpenGL
The One: A Singleton Discussion
Using Managers
The Singleton Class Cluster

Singleton Pattern (wikipedia)
Singleton Pattern (c2 wiki)
Singleton Considered Stupid
Use your singletons wisely
Why Singletons are Evil
Singletonitis

It's a fairly straightforward observation that the complexity of software increases as functionality and flexibility are increased. This manifests itself across the codebase. You can see it in the basic interfaces and APIs, in the user interface, and in the checkbooks as you spend millions of dollars maintaining a mess of super flexible goo of code. Good software strives for simplicity, and elegance, not infinite configurability. Don't try to design systems that solve every conceivable problem that could arise. If an unforeseen problem does arise, refactor to it, keeping things as simple as is reasonable.

Every developer should know a large variety of languages. Lisp, Ocaml and/or Haskell, assembly, and C are on my list of important languages to know. Personally, I would not advocate developing in any of these languages (well, maybe Haskell), and I give my condolences to those of you who are forced to. Still, it's important to know these languages and many others because they give you a wider pool of knowledge and ideas to draw on. Many modern ideas in C++ are borrowed from Lisp, albeit in a rather contrived and roundabout manner. Software engineering isn't just about knowing the language you happen to be using and keeping a copy of Design Patterns on your desk. The more languages you learn, the more tools you have at hand, no matter what you're developing.

And I mean it. There is no correct way to use a singleton. There is no situation in which it makes sense. Not for logging, not for resource managers, and certainly not for your renderer or related objects. Everyone I've talked to has been a little bit hazy here, saying that maybe, in a particular scenario, a singleton could be a good solution. I am rejecting that outright. Singletons are a useless antipattern. If you have one, your design is broken.

1. The official spec doc is completely useless; you have to refer to the extension specs for any kind of useful information.


2. The extensions thing is irritating, and you usually end up using several dozen by the time you're done doing anything vaguely serious.


3. Everything's a freaking GLuint. I end up wrapping things up in classes for textures, VBs, IBs, etc in order to get real type safety. By the time I'm done, things pretty much look like D3D.


4. Can't store vertex declarations in a convenient object, like you can in D3D. I usually end up writing vertex declarations myself and building a function that calls *Pointer functions appropriately.


5. Every time you change VBO, your vertex setup is trashed and you have to call all the Pointer functions again.


6. Binding to do everything means you can't even make simple assertions about the state of the pipeline between two draw calls. That is, when I'm getting ready to submit a batch, I cannot guarantee that the current VBO has not changed since the last draw call, because any MapBuffer, BufferData, etc calls in the middle probably included a BindBuffer.


7. No way to compile a GLSL shader into a quickly loadable binary form.


8. No coherent SDK type docs. If you want to find out about something, you figure out what it was named when it was an extension, and look it up.


9. Lack of a tool suite comparable to D3D (debug runtime, PIX). There are a few passable tools for free, and then there's gDEBugger, if you can afford to shell out for it. There's just so much more that's readily available in D3D.


10. Lots and lots of unnecessary cruft in the API. To be fair, D3D 9 is guilty too. Both D3D 10 and OGL 3 seek to solve this problem; the difference is that one has materialized as a product.


11. FBO and antialiasing don't mix. (Ok, so this is actually Ysaneya's complaint, but I'm willing to take his word on it.) There's a new extension for this, but only the GeForce 8 series exposes it.


12. GLSL can't be used on hardware that predates shader 2.0. This is getting less important as time goes on, but it's an irritating limit in the meantime.


13. Developing GLSL on an NVIDIA card is a pain, because they simply run it through a slightly modified Cg frontend. Long story short, a lot of illegal GLSL code will pass through on NVIDIA hardware, whereas ATI will flag it appropriately.


14. There are some bizarre cases of strictness in GLSL. For example, there's no implicit casting of literal integers to floats/doubles. So a 1.0 will compile, but 1 will break.


15. You can't really query if all GLSL functionality is available or not. The singular example is the noise() function. Very nearly nobody implements it, choosing instead to return a constant (usually black). You can't detect this failure, at all.


16. Lack of a D3DX equivalent. Math, image loading, etc. Getting a simple OpenGL application working without completely reinventing the wheel requires tapping about a half dozen libraries.


17. Related to the above, there's no D3DX Effect style functionality. If you've ever had the misfortune of working with CgFX, you know it's not really a great option.


18. You can't change the multisample mode without destroying the entire render window outright.


19. You can't create an FBO that is depth and stencil without another depth_stencil extension. That extension exists in NV and EXT forms, but no non-NVIDIA cards currently make it available.