As initially mentioned, the class sf::Music has semantics that are very different from other resource types. This begins already with its openFromFile() method that is not compatible to the loadFromFile() call in our implementation. Because of its streaming nature, a music object cannot be shared between multiple clients—each object represents one point in time of a certain music theme. No object contains the whole music data at once.

Instead of forcing sf::Music into a concept it does not fit, we decide to not store it inside ResourceHolder instances. This does not imply that there will be no encapsulation for music; we are rather going to cover music handling in-depth during Chapter 9, Cranking Up the Bass – Music and Sound Effects.

There is one resource type we ave yet to cover: shaders. Since a SFML shader object can consist of a fragment and/or a vertex shader, the interface of sf::Shader deviates slightly from the other resource classes in SFML. sf::Shader provides two methods to load from a file:

bool loadFromFile(const std::string& filename, sf::Shader::Type type);
bool loadFromFile(const std::string& vertexShaderFilename, const std::string& fragmentShaderFilename);

The first function loads either a fragment or a vertex shader (which one is specified by the second parameter). The second function loads both a vertex and a fragment shader.

This interface is an issue for our generic implementation, because ResourceHolder::load() contains the following expression:

resource->loadFromFile(filename)

Which assumes that loadFromFile() is invoked with one argument. For sf::Shader, we have to specify two instead.

The solution is simple: we write an overloaded ResourceHolder::load() function that takes an additional parameter and forwards it directly as the second argument to sf::Shader::loadFromFile(). This parameter can have the type sf::Shader::Type or const std::string&. In order to cope with both types, we add a function template parameter. Our new load() function has the following declaration:

template <typename Parameter>
void load(Identifier id, const std::string& filename, const Parameter& secondParam);

The function definition is listed in the following code. Do not confuse yourself by the two template parameter lists; the first one is required for the class template ResourceHolder and the second one for the function template ResourceHolder::load(). In the function body, only the loadFromFile() call is different from before.

template <typename Resource, typename Identifier>
template <typename Parameter>
void ResourceHolder<Resource, Identifier>::load(Identifier id, const std::string& filename, const Parameter& secondParam)
{
    std::unique_ptr<Resource> resource(new Resource());
    if (!resource->loadFromFile(filename, secondParam))
        throw ...;

    ... // insertion like before
}

A nice side effect of this additional overload is that it enables other argument combinations for loadFromFile() too. The method of sf::Texture actually looks as shown in the following line of code:

bool loadFromFile(const std::string& filename, const IntRect& area = IntRect())

The default parameter can be used if we want the texture to load only a rectangular area of the image. Usually, we do not specify it and load the whole file, but thanks to our second load() overload, we have now the possibility to use this parameter.

In our complete implementation, we have written a separate function that inserts resources into the map, in order to reduce code duplication.

Using the new ResourceHolder class template, we can visualize a possible in-game situation in the following diagram. On the left you see two resource holders, one for textures and one for fonts. Each one contains a map of enumerators to resources. The player's Aircraft class on the right stores a sprite that points to a texture, as well as a text that points to a font.