resource manager

[lorence30]

std::map doesnt store the pair if the key  has conflict
ie:

std::map<std::string,int> test;
test["One"] = 1;
test["One"] = 2;
std::cout << test.size(); // outputs 1

so in the resource manager of sfml essentials book
why it still need to check if the requested resource to load is already loaded before loading?

[Ungod]

It actually does store the pair and overrides the old one if there is a conflict. So when you doesnt check before loading, you load twice.

Try output test["One"] after inserting 1 and 2.

[SeriousITGuy]

A better solution would be to look up the key in the map, and if the returned iterator equals std::end() you can savely insert, otherwise just return the already inserted value (actually only the second value of the std::pair).

And btw. is the resource manager of SFML Essential a rather bad example overall, badly implemented singleton and stuff. You may want to consider the book SFML Game Development, as it gives a much better implementation of a resource manager class.

[Mario]

To expand a bit on the previous answers, a very simple resource manager would always work a bit like this:

std::map<std::string, sf::Texture> textures;

sf::Texture& getTexture(std::string file) {
    std::map<std::string, sf::Texture>::iterator a = textures.find(file); // Try to find an existing texture entry.
    if (a != textures.end()) // We've got one
        return a->second; // Return it

    // Load a texture and return it:
    if (!textures[file].loadFromFile(file))
        ;// Here you'd create some warning or similar

    return textures[file];
}

The call to textures[file].loadFromFile(file) has some "magic" in it. When using operator[] to access a member of the map, it is created, if it doesn't exist. Therefore we can just use the returned (new) texture object and try to load the file.

Note that this implementation always returns a valid texture object, even if loading fails (you'd just get pure white rather than a texture).

To free all textures when the program is shutting down (or you'd like to clear your loaded textures in some way), all you have to do is calling textures.clear();.

[grok]

there's a good explanation what might be improved in the sample presented above (it is about std::map access): http://www.youtube.com/watch?feature=player_detailpage&v=fHNmRkzxHWs#t=1430

I am not going to start holy war, just my two cents:
I wouldn't use map here, because map is bad (speaking about the memory layout), I'd use std::vector and be happy with it. Even if I had used map, I'd prefer std::unordered_map with some integer or, better, enum as a key, instead of a std::string.

[Mario]

No prob, also I'm often just stuck in C++98 land.

Edit: After watching the video, yeah, it works, because you're in the end guaranteed to actually use the entry you looked up (so no need to use the iterator to begin with). But I don't necessarily agree on the key/entry having to be determined over and over again as I'd assume the compiler optimizes this part for me.