Just a few classes for managing loading, creating and destroying bitmaps. I'm a bit rusty with C++ so if anyone sees some obvious mistakes / stylistic horribleness it would be nice if he/she could point it out to me.

misc.h

#pragma once
struct Position {
   int x;
   int y;
};

sprite.hpp

sprite.cpp

Main file to demonstrate use:

That's what I'm doing. A level description includes the entities that appear in it, and those know which sprites they need. Upon loading a level, I'm first loading all sprites that I need from the first one, and then free those needed by the second one. Since most levels will share at least a few entities, that way I get faster load times basically for free.

My sprite manager manages sprites. It's in the name. Except for rare exceptions, all resources are loaded at the beginning of the level and destroyed at the end of it. The SpriteManager is basically there to move the resource management logic out of the level class.

What this has to do with my shared_ptr's I didn't understand though.

I just told you, levels are aware of the resources that are used within them and keep them alive. The only ones for which this does not apply are temporary resources like movies etc that are only used once anyways.

I don't see how this is a misuse. Clearly they CAN be used this way, and it achieves exactly what I want. I am flattered that you apparently like my code so well that your only complaint about it is that it doesn't meet your personal idea of handling responsibilities though.

Of course THIS class doesn't do this, it isn't supposed to. All my SpriteManager is supposed to do is create valid sprites and ensure they and their copies are valid while in use (my implementation frees sprites the moment noone uses them anymore, but I could easily swap the implementation, for example to set a timeout before the sprites are released). That's all. The rest is handled by the classes using the SpriteManager. I think your problem is that you don't care about how I might be using this class, you just try to (mentally) insert it into your own code and find out it doesn't do what YOU want it to do.

It does keep the sprites alive for as long as I want them to. I already told you that levels are aware of the resources used within them and keep them alive, what more do you need? Your judgment is completely biased because you keep trying to shoehorn my class into usage patterns it wasn't designed for. It's a very simple premise - I am making the guarantee that if anyone has a sprite, it's valid. I'm also making the guarantee that while anyone holds a sprite, this sprite will not be reloaded. This is the intended behavior. If you don't like that, fine. But don't call my work garbage because it doesn't solve problems it isn't supposed to solve. Thank you very much.

So, me being unimpressed by you calling something that works garbage and stupid without actually pointing out any concrete problems with it or offering a substantially better approach now means that I'm some whiny kid that needs confirmation? Wow.

You have a list of stupid people? And I'm in it? Oh noes.
You're also on my list. You're a nice person but an incompetent programmer.

I have infact pointed out concrete problems before you started with your accusations and prompted me to call your class stupid.
Let me try it again. On the bottom line, you want a resource manager and you only want to create or destroy resources before the level starts. If you think about it, it makes sense for the resource manager to manage your resources. How can you manage resources? You can create them, destroy them or lend them. It makes no sense to take two thirds of those responsibilities and give them to a completely unrelated class. It's bad design and makes no semantical sense. You basically overcomplicate things needlessly (mess around with smart pointers), cause yourself some problems (how do I make sure the resources stay alive? Who do I offload the responsibility to?) and then solve them with more hacks and needless complexity. The sane thing to do is to lend ordinary pointers and do:

void onLevelLoad(...)
{
   resourceManager.refresh(resourceList);
}

Sure, there's nothing to prevent some vicious coder from calling delete on those pointers, but you can easily do the same with a smart pointer.

Where is all this vitriol coming from?

Now, that's not entirely fair to say that. I probably should not have been such a d*ck about it, but this isn't about me having a disagreement with OP. This is about OP asking for opinions, me pointing out some obvious flaws with his design and OP starting to get all defensive, telling me the flaws are actually features of his clever design and hinting that I'm only bashing them because I'm biased and narrow-minded. I'm really sorry, but that is stupid. Just read the thread and see for yourself. I like it how you're so quick to judge.

Yours is inherently inferior because compared to the simple, obvious, no-brainer solution of returning ordinary pointers and explicitly refreshing the resources when a level begins, yours is less obvious, more complex, slower and worst of all, forces you to have an external list of resource instances. All that without offering any adventages whatsoever. It's also inferior because it makes no sense from a design and usage standpoint.

I'm not going to waste any more time on this. When your euphoria of having finished your first sprite manager is over, write down the end goals of a resource manager, try to contemplate some alternative ways to achieve these goals and see how they compare with your solution in terms of complexity and ease of use.

In terms of performance, the levels of indirection have a negligible effect compared to what will happen when the game needs to load sprites while the game is in progress : disk access + png decoding + moving data from RAM to video RAM.

No, I think it came from:

He pointed out a potential mistake/stylistic faux pas as requested but got flamed by OP for doing this.

A solution that is more complex, less obvious and without any practical adventages over the simple no-brainer solution, is silly in my book. I have demonstrated and explained that OP's solution is more complex and offers no practical adventages. You can argue otherwise and try to demonstrate that what I'm saying is simply false, but you can't just brush off my criticism, imply that I'm just biased and narrow-minded and expect me to be pollite to you, especially if you're the one who was asking for criticism in the first place. I like it how you seek out threads I'm active in to diss me but never offer any insight into the technical matter at hand. Go away, spammer. You are irrelevant to this discussion.