[size=2]There&#39;s currently no way to delete resources from the manager. This probably won&#39;t be a problem until there&#39;s multiple levels and I actually have a reason to delete resources.<br /> [size=2]I don&#39;t provide an unload function for this. Instead, I just have a resource cache per level. The way I have it set up is that between level loads there are two resource caches, the previous one and the new one. The new one tries to load images from the previous before going to disk. This means that images that are common between two levels (such as character sprites) are only loaded exactly once, provided each level references them in turn.<br /> [size=2]<br /> <br /> Not strictly necessary, just how I approached this.<br /> <br /> <br /> <blockquote><br /> A smart pointer isn&#39;t going to help with SDL_Surface because you dont just delete it; you have to call SDL_FreeSurface on it. This is why I made a holder. Putting it in a shared_ptr without a wrapper is going to result in incorrect behaviour and crashes.<br /> As SiCrane points out, you can manage a SDL_Surface using a smart pointer. If you are willing to do a bit of digging, it might even be possible to use an intrusive smart pointer, as SDL_Surfaces in clude a refcount member. I haven&#39;t investigated where it is used (I imagine in &quot;sub surface&quot; code, mainly), but the documentation lists it as &quot;read-mostly&quot;, which I assume means that advanced users can decide for themselves if it is safe to write to it.<br /> <br /> <br /> Either way, I would advocate wrapping the surface anyway, because you really want to present an immutable interface to the client code if you are going to allow them to be shared. Calls such as SDL_FillRect() and SDL_SetColorKey(), among others, can ruin your day if you aren&#39;t careful.<br /> <br /> <br /> <blockquote><br /> Truth be told, c++ is such a complicated language and I didn&#39;t have long to make my post; I couldn&#39;t explain all the problems with the OP&#39;s original design in one go. He now has to learn about STL containers, smart pointers, the rule of 3, RAII, copy constructors, assignment operators, virtual destructors, boost and how to build it, and SRP. I addressed the major issue: manual memory management, and imparted a few points of wisdom. <br /> Sorry, I should have broken my reply up. Only the first paragraph was aimed at you, the rest was aimed at the OP. I was trying to talk about how I would approach the problem, and how I would decompose it. I built on your example and the OPs, addressing the different ideas and potential problems. Like any design, there are trade offs to be made, there is rarely one right answer.<br /> <br /> <br /> I would always tend to hint at noncopyable even when I don&#39;t go into detail about it. It is safer that way, an interested OP would then research boost::noncopyable or post a follow up question when they go to use the code.