sf::Texture and sf::Image constructors with filename parameter

[dramcryx]

Hi, community.
I love this library for almost everyting excpet one thing - there are only default (excluding copy) constructors for texture and image class.
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). I actually think this will add some efficiency, please, tell me if I'm wrong.
So I can't make textures const as I have to use loadFrom...() method instead of direct initialization in class constructor.
I think there are reasons for those not to exist yet. Could you, please, tell me them?

[Laurent]

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("...");

[dramcryx]

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

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?

[Laurent]

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?

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.

[dramcryx]

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.

Tbh I don't use global values. I use class with const private fields.
I have a capsule class that contains std::list<sf::Sprite > (actually extended sf::Sprite) and they share the same texture and field scheme (18x18 array of FloatRect). That's why I want as much static constants as I can do.
I think I'll go for what you offered to me with these initializing functions. Hope inlining them will also not include themselves as subprograms.

P.S. Do you personally think that library will lost some Simplicity if you go try-catch way instad of bool functions?

[Laurent]

Tbh I don't use global values. I use class with const private fields.

You said static, and static member variables are initialized in global scope, like global variables.