Question

What is a good way to share an instance of an object between several classes in a class hierarchy? I have the following situation:

class texture_manager;

class world {
    ...
    std::vector<object> objects_;
    skybox skybox_;
}

I currently implemented texture_manager as a singleton, and clients call its instancing method from anywhere in the code. texture_manager needs to be used by objects in the objects_ vector, by skybox_, and possibly by other classes as well that may or may not be part of the world class.
As I am trying to limit the use of singletons in my code, do you recommend any alternatives to this approach? One solution that came to mind would be to pass a texture_manager reference as an argument to the constructors of all classes that need access to it. Thanks.

Answer 1

The general answer to that question is to use ::std::shared_ptr. Or if you don’t have that, ::std::tr1::shared_ptr, or if you don’t have that, ::boost::shared_ptr.

In your particular case, I would recommend one of a few different approaches:

1. One possibility is, of course, the shared_ptr approach. You basically pass around your pointer to everybody who needs the object, and it’s automatically destroyed when none of them need it anymore. Though if your texture manager is going to end up with pointers to the objects pointing at it, you’re creating a reference cycle, and that will have to be handled very carefully.

2. Another possibility is just to declare it as a local variable in main and pass it as a pointer or reference to everybody who needs it. It won’t be going away until your program is finished that way, and you shouldn’t have to worry about managing the lifetime. A bare pointer or reference is just fine in this case.

3. A third possibility is one of the sort of vaguely acceptable uses of something sort of like a singleton. And this deserves a detailed explanation.

You make a singleton who’s only job is to hand out useful pointers to things. A key feature it has is the ability to tell it what thing to hand out a pointer to. It’s kind of like a global configurable factory.

This allows you to escape from the huge testing issues you create with a singleton in general. Just tell it to hand out a pointer to a stub object when it comes time to test things.

It also allows you to escape from the access control/security issue (yes, they create security issues as well) that a singleton represents for the same reason. You can temporarily tell it to pass out a pointer to an object that doesn’t allow access to things that the section of code you’re about to execute doesn’t need access to. This idea is generally referred to as the principle of least authority.

The main reason to use this is that it saves you the problem of figuring out who needs your pointer and handing it to them. This is also the main reason not to use it, thinking that through is good for you. You also introduce the possibility that two things that expected to get the same pointer to a texture manager actually get pointers to a different texture manager because of a control flow you didn’t anticipate, which is basically the result of the sloppy thinking that caused you to use the Singleton in the first place. Lastly, Singletons are so awful, that even this more benign use of them makes me itchy.

---

Personally, in your case, I would recommend approach #2, just creating it on the stack in main and passing in a pointer to wherever it’s needed. It will make you think more carefully about the structure of your program, and this sort of object should probably live for your entire program’s lifetime anyway.