Pourquoi sf::Font n'a-t-il pas de constructeur prenant un nom de fichier ?

[Morovaille]

En voulant créer une sf::Text, je vois que j'ai à ma disposition :

Text (const String &string, const Font &font, unsigned int characterSize=30)

Mais quand je clique sur sf::Font, il n'y a que les constructeur par défaut et le constructeur par copie.

Du coup, j'ai l'impression que le constructeur de sf::Text n'est pas très utile. Si dans une classe j'ai un sf::Text, je ne peux pas l'initialiser avec ce contructeur, puisqu'il faut d'abord appeler la méthode loadFromFile de la sf::Font. Je ne sais pas si je suis très clair.

Pourquoi ne pas surcharger le constructeur de sf::Font de façon à charger la police comme avec les trois méthodes loadFromFile, loadFromMemory et loadFromStream ? Avec une méthode pour vérifier ensuite que tout s'est bien passé. Ou une exception lancée par le constructeur, pourquoi pas.

Enfin bref, si quelqu'un a une info là-dessus, merci.

Edit :

Pour le moment, je fais un truc comme ça :

namespace
{
        inline sf::Font *
        get_font(std::string const & file)
        {
                auto font(new sf::Font());

                font->loadFromFile(file);
                return font;
        }
}

class Foo
{
        std::unique_ptr<sf::Font> _font;
        sf::Text _text;
public:
        Foo() :
                _font(get_font("my_font.ttf")),
                _text("text", *_font)
        {}
};

Ce qui est un peu lourd... Et je pense que ce(s) nouveau(x) constructeur(s) serviraient à tout le monde.

[Laurent]

Les constructeurs des classes de ressources ne font rien, car SFML n'utilise pas d'exception. Si la gestion d'erreur passe un jour aux exceptions (probablement dans SFML 3), il est possible que nous donnions plus de responsabilités aux constructeurs, et qu'on puisse effectivement écrire des choses du genre

sf::Font f("abc.ttf");

Maintenant concernant ton exemple en particulier... je ne comprends pas ton problème. Le constructeur de sf::Text est tout à fait utile pour écrire ce genre de choses :

sf::Font font;
font.loadFromFile("abc.ttf");

sf::Text text("blop", font, 16);

Si ce que tu avais en tête est ceci :

sf::Text text("blop", sf::Font("abc.ttf"), 16);

... alors ça n'a aucun sens puisque la font, qui serait alors une instance temporaire non nommée, serait détruite immédiatement après la construction du sf::Text, et celui-ci garderait une référence vers une variable qui n'existe plus. Dans tous les cas, la durée de vie de la font doit être supérieure à celle des textes qui l'utilisent, donc il faut bien la construire et la charger avant de la lier à des sf::Text. L'ajout que tu proposes n'y changerait strictement rien.

[Morovaille]

Je me suis mal exprimé. L'ajout que je propose permettrait de faire ceci :

class Foo
{
        sf::Font _myfont;
        sf::Text _mytext;
public:
        Foo() :
                _myfont("abc.ttf"),
                _mytext("text", _myfont)
        {}
};

Ce qui évite de faire de l'allocation dynamique (j'évite autant que je peux toute allocation dynamique en C++).

(J'ai aussi édité mon premier message pour être plus clair).

[Laurent]

Même si c'était possible je ne le ferais pas. Il suffit que par mégarde tu inverses l'ordre de déclaration de _myfont et _mytext dans ta classe, et ça ne fonctionnera plus. En règle générale, il vaut mieux éviter que la validité de ton code dépende d'un ordre implicite dicté par les règles du C++ (c'est pareil pour la construction des variables globales, par exemple).

Ce qui évite de faire de l'allocation dynamique

?? Pas besoin d'en arriver là.

class Foo
{
    sf::Font _myfont;
    sf::Text _mytext;
public:
    Foo() :
        _mytext("text")
    {
        _myfont.loadFromFile("abc.ttf");
        _mytext.setFont(_myfont);
    }
};