sf::Texture::Texture(std::string file)

[kim366]

Please make a constructor, that has sf::Texture::loadFromFile(string file) built in.

Thank, you, SFML is great! 

[cob59]

How would you know whether the loading failed?

[Lo-X]

How would you know if the loading failed?

Make the program crash with an error number like -1256478 and make it really hard to find in the documentation

[cob59]

 

[Jesper Juhl]

How would you know whether the loading failed?

I can think of 3 options:

1) throw an exception.

2) have the ctor take an extra non-const reference argument (out parameter) that recieves a status code or bool indicating success.

3) provide a member function that can be called after construction to determine if the object was correctly constructed.

Obviously 2 & 3 are too ugly to even consider and since SFML doesn't use exceptions 1 is out as well.

[Laurent]

Maybe we'll do it when SFML uses exceptions. I don't know yet.

[Lo-X]

We are making a bit of fun of it, but more seriously, if you have some kind of centralized textures manager, the call will be done once. If not, well, that's juste one extra line, not the end of the world

Exceptions would be the only clean solution I can think of, but yeah it would require to add them through the whole lib.

[StormWingDelta]

Maybe we'll do it when SFML uses exceptions. I don't know yet.

hmm maybe you should put exceptions where they need to be like the loading and saving stuff to start with?  

[thomas9459]

Exceptions won't be added into SFML 2.x, as they would be too major of a change, but they will most likely be added in SFML 3.

[Laurent]

hmm maybe you should put exceptions where they need to be like the loading and saving stuff to start with?

And what's Texture::Texture(std::string) if not a loading function?

[Nexus]

Even with exceptions, constructors are a bad idea, because they can be ambiguous with overloads, and the call is not expressive in code. Rather use named constructor idiom + move semantics.

[kim366]

I would just like to be able to do

Code: [Select]

window.draw(sf::Sprite(sf::Texture("texture.png")));
or

Code: [Select]

window.draw(sf::Sprite(sf::Texture::loadFromFile("texture.png");
and maybe instead of an exception have a variable, like

Code: [Select]

bool sf::Texture::loadSuccess

[eXpl0it3r]

This is very inefficient code and we certainly don't want to support it by adjusting SFML.
Loading a file needs access to the hard disk which is a very costly procedure, thus it should be done once and not every frame iteration.

[Laurent]

And the sprite does not own the texture, so you can't construct a sprite from an unnamed temporary texture.

So... anything that prevents you from doing what you want is a good thing

Are you coming from a language with GC, like C#?

[FRex]

And the sprite does not own the texture, so you can't construct a sprite from an unnamed temporary texture.

The way he does it (temporary sprite around temporary texture) works, but it's still insanely inefficient.