Why does sf::Music have another loading method?

[UserXY]

Why does sf::Music load its file via OpenFromFile?
It would be easier to write a resource-manager if it would be uniform,
just like sf::Image, sf::Font, sf::SoundBuffer etc.

Regards, UserXY

[Laurent]

It's not a LoadFromFile. Because music is streamed, it is loaded continuously while it is played.

Musics and other resources really don't have the same semantics, it would be an error to make a generic manager that can handle them all the same way. That was also a reasno for me not to name it LoadFromFile.

[Nexus]

Musics and other resources really don't have the same semantics, it would be an error to make a generic manager that can handle them all the same way.

That's an interesting point. I think it's good to know the difference between loading and streaming, but doesn't the usage in the end look similarly for many cases? Or could you explain why one shouldn't use a resource manager with the same structure for sf::Music and (e.g.) sf::Image?

[Laurent]

First, technically it will most likely not compile with the same structure. A manager of sf::Image/sf::SoundBuffer/sf::Font will have a container of instances, while a manager of sf::Music will have a container of pointers.

Secondly, images/sound buffers/fonts are plain resources, once loaded they can be used directly or copied. A manager of them is just a solution to avoid loading several times the same resource.
A music is an entity, it has a thread running in background, an internal state, etc. It's not just a storage for some data. You must play/pause/stop the instance that you "load", it cannot be copied.
A manager of musics... well it makes no sense at all, actually. If you need to play a music then you will most likely create and open your own instance everytime, there's no shared music data that a manager can provide you.

I hope it's clear enough (sorry if it's not, it's 1 AM and I'm still at the office).

[Nexus]

Yes, it's clear, thanks a lot

You're right, there are a lot of differences between sf::Music and the other resources that aren't obvious at first glance. There is no layer (like Sprite for Image, Font for Text or Sound for SoundBuffer), and as you say shared access to sf::Music is not meaningful. In fact, a constant sf::Music is not useful at all (unlike the other resources which can still be read).

By the way, what about sf::Shader? I think it behaves similarly to images, even though there are no methods for direct reading access. Or wouldn't you put shaders into managers?

The reason why I asked, is that I've recently written such a manager and haven't taken the special semantics of sf::Music into account. I developped the manager mainly because of two advantages: Automated loading with error-handling, and safe shared access. While the second point doesn't apply anymore, the first might still be useful. Maybe I should remove sf::Music for now, or is there another approach (I know it's hard to say without knowing my design exactly, but maybe there is something like an established best practice )?

[Laurent]

By the way, what about sf::Shader? I think it behaves similarly to images, even though there are no methods for direct reading access. Or wouldn't you put shaders into managers?

sf::Shader is in between the two worlds. It's completely loaded after a call to LoadFromFile, but it as an internal state as well (modified when you call SetParameter or SetTexture). But as long as it has a copy constructor and LoadFromXxx functions, you can assume it is similar to sf::Image/sf::SoundBuffer/sf::Font. And this is my job to ensure that the copy is robust (currently it is not, parameters are not copied).

Maybe I should remove sf::Music for now, or is there another approach (I know it's hard to say without knowing my design exactly, but maybe there is something like an established best practice)?

No, no best practice

[Nexus]

Okay, then I probably leave sf::Shader for the next time as it is. I will try to find out if there is something I can do about sf::Music, otherwise I might remove it...

Thanks!

[UserXY]

Thank you for your answer, it really makes sense.