I think there are reasons for those not to exist yet. Could you, please, tell me them?
The reasons are that you must be able to retrieve the loading state (true/false) when you load an image or a texture, and a constructor doesn't return anything.
This leads to discussions about error handling, exceptions, etc. but this is a complex topic ;)
It puts me in some trouble because I would like some static const textures and images (then they are read-only, it's safer for multi-threading)
Thread-safety is never achieved with const. You need synchronization primitives in any case.
So I can't make textures const as I have to use loadFrom...() method instead of direct initialization in class constructor.
sf::Texture makeTexture(const std::string& filename)
{
sf::Texture t;
t.loadFromFile(filename); // put some log on failure at least, but beware of global objects initialization order
return t;
}
const sf::Texture MyClass::texture = makeTexture("...");
This leads to discussions about error handling, exceptions, etc. but this is a complex topic ;)
That's good but let me ask then - why it cannot be smth like
sf::Texture(const std::string &filename) throw(sf::exception::loadingError) //or std::runtime_error for example
that one?
Thread-safety is never achieved with const. You need synchronization primitives in any case.
I didn't really mean this. I mean that I would like to copy static const texture to each sf::Sprite in my std::list<>, for example. This can be done parallel, right? ::) But I'm not sure it will happen if it stays mutable. Nevermind :-X
sf::Texture makeTexture(const std::string& filename)
{
sf::Texture t;
t.loadFromFile(filename); // put some log on failure at least, but beware of global objects initialization order
return t;
}
const sf::Texture MyClass::texture = makeTexture("...");
I actually did think about several of these initializing functions that would provide me all constants I need. Even if I can make them inline, don't you think it looks sort of workaround? ;D
That's good but let me ask then - why it cannot be smth like
sf::Texture(const std::string &filename) throw(sf::exception::loadingError) //or std::runtime_error for example
that one?
As I said, error handling is definitely something we'd like to change in SFML 3, but it's another subject (already discussed elsewhere), let's not start a new discussion here ;)
I actually did think about several of these initializing functions that would provide me all constants I need. Even if I can make them inline, don't you think it looks sort of workaround? ;D
No. You can't request all the classes that you want to use, to be directly constructible the way you want. Writing your own initialization functions on top of what the API provides is not what I would call a workaround.
And... really, doing all this stuff at global initialization (before entering main), is not only UB (because some global SFML objects may not be created yet), but also not really a great idea for handling errors, logging, etc.