Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: sf::Texture and sf::Image constructors with filename parameter  (Read 5418 times)

0 Members and 1 Guest are viewing this topic.

dramcryx

  • Newbie
  • *
  • Posts: 7
    • View Profile
    • Email
sf::Texture and sf::Image constructors with filename parameter
« on: January 03, 2019, 10:49:57 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: sf::Texture and sf::Image constructors with filename parameter
« Reply #1 on: January 04, 2019, 07:31:32 am »
Quote
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 ;)

Quote
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.

Quote
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("...");
« Last Edit: January 04, 2019, 07:33:22 am by Laurent »
Laurent Gomila - SFML developer

dramcryx

  • Newbie
  • *
  • Posts: 7
    • View Profile
    • Email
Re: sf::Texture and sf::Image constructors with filename parameter
« Reply #2 on: January 06, 2019, 12:06:55 am »
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?

Quote
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

Quote
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

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: sf::Texture and sf::Image constructors with filename parameter
« Reply #3 on: January 06, 2019, 09:18:03 am »
Quote
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 ;)

Quote
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.
Laurent Gomila - SFML developer

dramcryx

  • Newbie
  • *
  • Posts: 7
    • View Profile
    • Email
Re: sf::Texture and sf::Image constructors with filename parameter
« Reply #4 on: January 06, 2019, 12:48:48 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: sf::Texture and sf::Image constructors with filename parameter
« Reply #5 on: January 06, 2019, 04:24:05 pm »
Quote
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.
Laurent Gomila - SFML developer

 

anything