Discussion :

[méphistopheles]

Bonsoir

Après avoir lu cet article de la faq, je suis tombé sur un cas concret et je me trouvais embêté de ne pas savoir lequel choisir.

voici une représentation de la classe en question:

Code :

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

1
2
3
4
5
6
class A{
public:
   explicit A(unsigned int);
private:
   A(int);
};

Or pour certaines raisons, je veux dans une méthode de la classe appeler le premier constructeur alors que je manipule(peut-être) un int. La question est alors: lequel des trois codes est alors préférable ?:

Code :

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

   return A(static_cast<unsigned int>(mon_int));

Code :

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

   return A(reinterpret_cast<unsigned int>(mon_int));

Code :

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

   return A((unsigned int)mon_int);

Merci d'avance

[Laurent Gomila]

- Le premier effectuera la conversion de la valeur en unsigned int (ce que tu veux)
- Le deuxième ne compile pas; mais imaginons qu'il compile : il ferait croire au compilateur qu'il y a un unsigned int à l'emplacement mémoire où se trouve en réalité un int -- tout ce qu'il faut pour récupérer une valeur incorrecte
- Le troisième est dans tous les cas à éviter

[méphistopheles]

- Le premier effectuera la conversion de la valeur en unsigned int (ce que tu veux)

A la compilation ou à l'execution ?

- Le deuxième ne compile pas

Heu, je sait que la question peut paraître impertinente voir déplacée, mais... pourquoi ?

il ferait croire au compilateur qu'il y a un unsigned int à l'emplacement mémoire où se trouve en réalité un int -- tout ce qu'il faut pour récupérer une valeur incorrecte

En réalité, ce n'est pas une variable mais une opération qui est reinterpret_castée ce qui signifie que la variable en question est une variable qui sera effacée à la ligne suivante.

- Le troisième est dans tous les cas à éviter

Une fois encore, et en te priant d'excuser l'outrecuidante impétuosité dont je fais preuve dans mes ineptes interrogations, je me permettrais de réitérer, l'insolente, la succincte, l'enfantine et pourtant diabolique et fatale question: Pourquoi ?

En espérant une réponse de haute volée.

Cordialement

[Matthieu Brucher]

A la compilation ou à l'execution ?

A l'exécution, c'est toujours à l'exécution un transtypage ! Mais comme il connaît les types, ça se fera tranquillement.

Heu, je sait que la question peut paraître impertinente voir déplacée, mais... pourquoi ?En réalité, ce n'est pas une variable mais une opération qui est reinterpret_castée ce qui signifie que la variable en question est une variable qui sera effacée à la ligne suivante.

Il n'y a pas de cast effectué en réalité. Ca dit de réinterprété le contenu de la case comme un entier non signé, ce qui pose problème une fois sur deux.
Imagine que c'est un flottant...
En réalité, les reinterpret_cast, ça marche sur les pointeurs, ça permet de modifier le type sous-jacent.

Une fois encore, et en te priant d'excuser l'outrecuidante impétuosité dont je fais preuve dans mes ineptes interrogations, je me permettrais de réitérer, l'insolente, la succincte, l'enfantine et pourtant diabolique et fatale question: Pourquoi ?

Parce que !
C'est un cast C-like, dans ce cas ça sera équivalent à un static_cast, mais dans d'autres, ça sera un reinterpret_cast. Donc à éviter.

[Médinoc]

C'est un cast C-like, dans ce cas ça sera équivalent à un static_cast, mais dans d'autres, ça sera un reinterpret_cast.

Ou pire, un const_cast.

[koala01]

Salut,

Une fois encore, et en te priant d'excuser l'outrecuidante impétuosité dont je fais preuve dans mes ineptes interrogations, je me permettrais de réitérer, l'insolente, la succincte, l'enfantine et pourtant diabolique et fatale question: Pourquoi ?

En espérant une réponse de haute volée.

Cordialement

Simplement parce qu'un transtypage prenant la forme de

Code :

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

(unautretype)variable

est un transtypage issu du C et qu'il subit toutes les limites de son prédécesseur...

Le C est un langage faiblement typé dans lequel tu *peux* décider à n'importe quel moment de transtyper n'importe quoi en n'importe quoi d'autre, sans que le langage n'aie le moyen de vérifier que la conversion soie possible.

Cela signifie que, si tu n'y prend pas garde, tu puisse en arriver à faire passer un spagetti pour... une voiture

Le C++ quant à lui est, en tout cas, plus fortement typé, et fournit une série de possibilités qui nous permettent de nous assurer qu'une conversion est - au minimum - cohérente (que le spagetti ne soit jamais considéré comme autre chose qu'un aliment... avec sans doute même quelques restrictions)

C'est la raison principale pour laquelle nous conseillons régulièrement de préférer toutes les possibilités offertes par le C++ à l'équivalent qui serait fourni par le C

[méphistopheles]

Merci beaucoup


et moi qui croyais que la conversion (untype)unautretype étais propre au C++...

bon, ben du coup, j'ai quelques lignes à recoder, mais heureusement que le replace existe


Merci encore