Question

I’m pretty new to C++ and am writing a cross-platform (desktop/mobile) 2D game engine… my question is, am I using singletons in an appropriate manner and if not, is there an alternative?

Basically I have a few components to my engine which are built around a singleton object. Examples:

VBOManager (Singleton)
This “manager” is basically responsible for allocating and of course, “managing” vbo’s that are used to store texture mapping and vertex coordinates. I control “read/write” through this object so I can cache data written to the vbo by other objects and return pointers (avoiding storing duplicate data like 500 sprites with the same mapping and vertex coordinates).

TextureManager (Singleton, self explanatory)

GLUtils (Singleton)
I pretty much use this for unifying common GL calls which are different based on the current platform, like GL or GLES. Example, GLU functions (libglu isn’t on android so I have a custom implementation)

Graphics (Singleton)
Used to handle things like window initialization and resizing, global framerate management, viewport initialization etc.

InputManager (Singleton, self explanatory)

Anyway so here I am reviewing all of this and I’m starting to feel really, really dirty. I do feel that given the requirements and functionality of the given objects, it’s justified. But on the other hand I’m a newbie and something just doesn’t feel right about having this “pattern” so rampant throughout my code. If the latter is indeed the case, what might be an alternative?

Answer 1

Before I begin, I want to make to clear what we’re talking about so that we’re all on the same page. A Singleton is:

1. “an object,” This means that it has certain internal state, which is encapsulated from direct external access. It has a lifetime: it is created at some point in the program’s execution, and it is destroyed at some later point.
2. “of which no more than one instance can be created,” This means that there is some explicit machinery in place that forcibly prevents creating multiple instances. The constructor and destructor will be called no more than once in the program’s execution.
3. “which is globally accessible.” The instance, once created, is accessed either via a global function call or a public static member of a class.

A global object is not a singleton; it is simply a global object. If it is possible to make more than one, it is not a singleton.

Now that the definitions are out of the way:

VBOManager (Singleton)

I cannot imagine how this object works in any way that makes sense. Buffer objects are, in terms of OpenGL, free-standing constructs. They have no relation to one another. So I don’t understand why you would need a manager that handles all of them.

I can understand having a specialized wrapper buffer object class for dealing with streaming buffer objects. There are several ways to do streaming, and some are more performing than others. So it makes sense to wrap that in an object.

But to have a global buffer object manager does not make sense. Buffer objects should be independent of one another. Or if anything, they should be dependent on other objects like Meshes (multiple mesh objects can reference the same buffer(s)). But you shouldn’t need to have a global buffer object manager.

I can understand having a repository of named objects from which you can add and retrieve. But I don’t understand the need to have it for specific object types like this. And the need for it to be a global singleton is… dubious.

I find that singletons are best for concepts that are fundamentally unique. There is one filesystem, and therefore it makes sense to have a global filesystem. OpenGL itself is global (owing to its C-based nature), though even then, it is possible to switch rendering contexts. If it ever makes sense to have two of something, then a singleton probably isn’t the best way to go.

Even if you are only using a single buffer object, and have a manager for it, there is no need to make this class a singleton. You can make it a global if you like, but there is no need to forcibly prevent users from creating more than one instance of this class. If later, you want to have multiple buffer object managers (and possibly pay the performance price), so be it.

GLUtils (Singleton)

Why is this an object? The Singleton pattern refers to an object that there can only ever be a single instance of at any one time. Utility functions are simply global functions.

C++ is not Java. You don’t have to put everything in a class. Global functions are not bad design. Indeed, they are good design, where appropriate. If a function doesn’t need to access any state (outside of its parameters and any other functions it might call), then there is no need for it to be part of an object.

Graphics (Singleton)

This is something for which one can argue that a Singleton makes sense. It is a living object with state. And you explicitly do not want more than one in your application.

However, consider this. Is it so wrong to have more than one? How often would you be passing around this Graphics object? How much code needs to work at the level of the Graphics object? I’m guessing not a lot. Some basic initialization code, and that’s it.

So while it is defensible, it isn’t necessary. It’s not a concept that requires being a Singleton. Plus, by being able to have more than one, you can delete it at any time and create a new one. This allows your application to be able to reconstruct the window more easily.

The one flaw with this is the possibility of having two Graphics objects at once. And that involves dealing with OpenGL contexts. Since an OpenGL context is global state, having multiple Graphics objects could cause problems, since both would have their own contexts. You would need some way to set a particular Graphics object as the current one, which would bind itself as the current OpenGL context (and retrieve any function pointers it needs to).