Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a resource manager that loads and returns resources. Currently I just return shared_ptrs for the resources I create, but I'm thinking about going over to using something like simple handles, whereby you get an ID you use to access the resource. The reasons are more explicit ownership and also less overhead rather than using smart_ptrs.

Are resource handles the most efficient way to access resources, should I stick with shared_ptrs or are there other alternatives?

The reason I am asking is that I was reading this article which made me wonder if I should implement something like that instead.


share|improve this question

I disagree with Vittorio about not needing shared ownership of resources and, while I dislike the implementation of shared_ptr, it can be made to work just fine.

You want shared ownership because, of course, multiple game objects might be using the same resource. More importantly, if you have multiple levels and want to minimum level loading, you need some way to compute the union and intersection of resources needed by both.

One way to do this, which does require something more than just a shared_ptr, is to allow "loading" a level without resources and letting it take shared ownership of resources it needs. Then unload the old level, removing its ownership. Then, for any resource that still has ownership active but isn't loaded, load the resource.

For a resource A needed by levels 1 and 2, the reference count goes something like:

load level 1
load A
load level 2
unload level 1

For a resource B used by only level 1, it goes like:

load level 1
load B
load level 2
unload level 1
ref=0 (removed)

And a resource C used by only level 2, it goes like:

load level 1
ref=0 (implicit, as no resource C exists)
load level 2
unload level 1
load C

One method might be to have a layer of indirection. You store shared_ptr to a ResourceHolder. These holders are also in a list of some kind. When loading a level, you create and hold on to these ResourceHolder objects. They contain a unique_ptr to the actual resource (initially nullptr) and the path or other information needed to eventually load the item.

After loading the new level and unloading the old, you can then iterate through the list of live ResourceHolder objects, find any that have a nullptr handle to the actual resource, and then load it. When the shared_ptr to a ResourceHolder hits a ref count of 0 and unloads it, it also naturally frees the resource, and you should ensure that it removes itself from the list of live resources.

You can do much better than shared_ptr but it's a perfectly fine place to start to get up and running. Optimize it into something better later on once you have a working game.

share|improve this answer
What are the benefits of shared resource ownership? Even if many objects require the same resource, they can simply store a reference or non-owning pointer to it. – Vittorio Romeo Jul 18 '13 at 18:48
I explained it in this post with reference count sequence examples. If you don't have shared ownership, you don't know when to unload or reload resources when you transition levels, unless you make the levels themselves owners (which is crappy, because I don't want to have to manually tag which resources each levels needs; I just want to add objects to a level resource and have it all work automatically). – Sean Middleditch Jul 18 '13 at 20:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.