Discussion :

[Bktero]

Bonjour,

Je suis en C++03 et j'ai un code comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
// Fonctions de la bibliothèque que j'utilise
virtual uint16_t TextArea::getTextWidth() const;
virtual void Drawable::setX(int16_t x);
virtual void Drawable::setWidth(int16_t width;
 
 
// Creation de mes drawables
Box background_m;
TextArea text_m;
 
 
// Code utilisant tout ce beau monde
enum
{
BACKGROUND_BORDER = 10
};
 
int16_t bw = text_m.getTextWidth() + BACKGROUND_BORDER * 2;
background_m.setX(width / 2 - bw / 2);
background_m.setWidth(bw);

Mon IDE CLion analyses le code à la volée (avec clang j'ai l'impression) et me lève un warning comme ceci sur l'appel à setX():

Warning:(39, 23) Parameter type mismatch: Values of type 'int' may not fit into the receiver type 'int16_t'

Que faire dans pareil cas ?

Merci pour vos conseils !

[Bousk]

Salut,

static_cast

[koala01]

Salut,

Clang a raison : tu essayes de faire entrer une valeur de type int (classiquement codé sur 4 bytes) dans une valeur codée sur 2 bytes. Voilà qui pourrait poser bien des problèmes, indépendamment du fait que l'on sait pertinemment bien que BACKGROUND_BORDER est "dans les limites" (une question que je me pose avec ton code: "what if" getTextWidth() venait à renvoyer une valeur égale à std::numeric_limits<int16_t>::max()-5 Tu serais un peu dans la merde, non ).

L'idéal, bien sur, serait de pouvoir modifier la signature de setWidth pour qu'elle accepte un int (qui devrait d'ailleurs être non signé, au passage), histoire de n'avoir plus de problème à ce sujet ou (mais ce n'est possible qu'en C++11 et ultérieur, donc impossible pour toi) de définir le type de l'énumération comme étant de type int16_t. Mais je me doute bien qu'il n'est pas en ton pouvoir de le faire

Du coup, la solution de Bousk est bel et bien la seule solution possible : dire à clang que tu sais que les types ne correspondent pas, mais que "tu sais ce que tu fais" (en priant pour que ce soit effectivement le cas, cf la question que je posais plus haut), et qu'il peut sans problème faire la conversion.

Juste un truc au passage: C++11 est sorti il y a maintenant six ans. C++14 est sorti depuis trois ans, et il est supporté par tous les compilateurs récents. Je me doute bien que tu n'as "pas voix au chapitre" sur ce coup, mais tu n'envisagerais pas de "donner un coup de pied dans la fourmilière" pour inciter les décideurs à mettre leurs outils à jour

[Pyramidev]

Salut,

Tu peux convertir tes entiers en int16_t avec boost::numeric_cast :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#include <boost/numeric/conversion/cast.hpp>
 
namespace DrawableUtil
{
    template<class IntegerType>
    void setX(Drawable& drawable, IntegerType x)
    {
        drawable.setX(boost::numeric_cast<int16_t>(x));
    }
}

Si l'argument est en dehors des limites de int16_t, cela lancera une exception boost::numeric::positive_overflow ou boost::numeric::negative_overflow.

[koala01]

En fait, je n'étais qu'à moitié sérieux quand je posais la question d'un éventuel dépassement de valeur, car, vu que l'on parle d'une fenêtre à l'écran, même en comptant en pixels en HD, on devrait toujours être dans une zone de sécurité à ce sujet.

Et puis, je suis plutôt d'avis qu'il faudrait une assertion et non une exception pour ce genre de dépassement, car c'est clairement le genre de chose auquel le développeur doit apporter une solution en cas d'erreur

[Pyramidev]

Et puis, je suis plutôt d'avis qu'il faudrait une assertion et non une exception pour ce genre de dépassement, car c'est clairement le genre de chose auquel le développeur doit apporter une solution en cas d'erreur

A mon avis, dans la plupart des cas de ce genre, des assertions ne serviraient à rien, à part encombrer le code.
En effet, admettons que l'on ait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
#include <limits>
 
namespace DrawableUtil
{
    template<class IntegerType>
    void setXAvecPrecondition(Drawable& drawable, IntegerType x)
    {
        assert(x >= std::numeric_limits<int16_t>::min());
        assert(x <= std::numeric_limits<int16_t>::max());
        drawable.setX(static_cast<int16_t>(x));
    }
}

Si on a des préconditions, c'est pour qu'elles soient contrôlées dans le code appelant.
Or, que fera le code appelant quand un argument sera trop petit ou trop grand ? Il lancera une exception.
Comme le code qui lancera cette exception sera toujours le même, il sera factorisé, par exemple comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#include <boost/numeric/conversion/cast.hpp>
#include <limits>
 
namespace DrawableUtil
{
    template<class IntegerType>
    void setXAvecPrecondition(Drawable& drawable, IntegerType x)
    {
        assert(x >= std::numeric_limits<int16_t>::min());
        assert(x <= std::numeric_limits<int16_t>::max());
        drawable.setX(static_cast<int16_t>(x));
    }
 
    template<class IntegerType>
    void setX(Drawable& drawable, IntegerType x)
    {
        static_cast<void>(boost::numeric_cast<int16_t>(x));
        setXAvecPrecondition(drawable, x);
    }
}

Le code appelant appellera directement DrawableUtil::setX plutôt que DrawableUtil::setXAvecPrecondition. Ainsi, on reviendra au point de départ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#include <boost/numeric/conversion/cast.hpp>
 
namespace DrawableUtil
{
    template<class IntegerType>
    void setX(Drawable& drawable, IntegerType x)
    {
        drawable.setX(boost::numeric_cast<int16_t>(x));
    }
}

On pourrait m'objecter que ce n'est pas DrawableUtil::setX qui devrait lancer l'exception, mais le code appelant, afin que le message de l'exception contienne des informations contextuelles.
Mais les deux idées sont compatibles. Si on veut concevoir un programme avec une gestion d'erreurs sophistiquée, ce que l'on peut faire, c'est travailler avec des types d'exception sophistiqués qui ont des constructeurs capables de capturer l'état de la pile et des fonctions pour accumuler des informations contextuelles.
Alors, dans DrawableUtil::setX, on aurait un code du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <limits>
 
namespace DrawableUtil
{
    template<class IntegerType>
    void setX(Drawable& drawable, IntegerType x)
    {
        if(x < std::numeric_limits<int16_t>::min())
            throw MaSuperExceptionEntierTropPetit(x, std::numeric_limits<int16_t>::min());
        if(x > std::numeric_limits<int16_t>::max())
            throw MaSuperExceptionEntierTropGrand(x, std::numeric_limits<int16_t>::max());
        drawable.setX(static_cast<int16_t>(x));
    }
}

Et, dans le code appelant, on aurait quelque chose du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
try {
    [...]
        // code qui appelle DrawableUtil::setX et d'autres fonctions qui peuvent lever
        // plein de types d'exceptions différents
 
} catch(MaSuperException& e) { // MaSuperException est une classe de base abstraite.
    e.ajouterInformationContextuelle("blababla");
    throw; // Bonne nouvelle : le type dynamique de l'exception n'est pas perdu.
} catch(...) {
    std::exception_ptr eptr = std::current_exception();
    const std::string infoContextuelle = "blababla";
    convertirEnMaSuperException_puis_ajouterInformationContextuelle_puis_repropager(eptr, infoContextuelle);
        // La fonction ci-dessus factorise un râteau de catch.
        // Le type dynamique de l'exception MaSuperException propagée dépend du type
        // de l'exception capturée dans eptr.
}

[CTJayce]

Je suis en C++03 et j'ai un code comme ceci :

T'es vraiment en C++03 ??? ou C++03TR1 ?
D'où sort-il ton int16_t ? Tout ça me laisse perplexe. Mon avis est que tu
compiles déjà, et au minimum, en C++11.

Essaye de voir ce que ça donne en typant ton énumération :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

enum : int16_t {BACKGROUNG_BORDER= 10};

ou mieux, faire un "#pragma message" sur "__cplusplus".

+/- HS:
Un fichier de configuration, pour moi, doit être validé au plus tôt et au court
du démarrage de l'application. Donc, très en amont. Parce que charger et
contrôler les données au fur et à mesure des besoins alors que l'application
est déjà bien avancée dans le "runtime", ça ne laisse présager rien de bon
pour l'utilisateur final.