Discussion :

[hpfx]

Bonjour,
pour faire plaisir a mon compileur, je vais effectuer un cast d'un Uint16 en Uint8,
quoi de plus simple me direz vous, surtout grace a la FAQ...
oui mais voilà...
ce bout de code se doit d'être le plus optimisé possible, hors de question que le compilo me rajoute du code en trop, c'est une section critique.

Code :

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

1
2
3
4
5
Uint8 a;
Uint16 tmp;
//...
// ici je sais que tmp est toujours inferieur à 256, promi juré!
a=tmp; //<- là le compilo me donne un warning... normal

Voilà, alors je me demande ec qu'il y a de plus optimisé en code :

Code :

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

a=(Uint8) tmp;

ou bien

Code :

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

a=static_cast<Uint8>tmp;

Merci.

l'objet de ce post n'est pas de savoir pourquoi tmp est un Uint16, alors qu'il semble qu''il aurait pu être un Uint8...

[Matthieu Brucher]

C'est la même chose. Mais le deuxième est du C++, le premier du C, parfois ça te donnera le bon résultat, parfois pas.

Cast du C -> poubelle.

[ram-0000]

...parfois ça te donnera le bon résultat, parfois pas...

Je ne comprends pas ta remarque, dans quels cas on risque de ne pas avoir le résultat attendu ?

[Matthieu Brucher]

Je ne comprends pas ta remarque, dans quels cas on risque de ne pas avoir le résultat attendu ?

Quand il y a un pointeur qui se balade, par exemple. Un static_cast fera toujours un transpyage pour transformer un type en un autre. Un reinterpret_cast va changer la vision de la mémoire pour qu'on croit qu'il s'agit un autre type. Un transtypage C va faire l'un ou l'autre selon le cas.

[Médinoc]

Disons que le cast C-style est à bannir dès que l'un des deux types (source/destination) est un pointeur.
Il en est de même du cast function-style, qui n'est qu'un cast C-style déguisé.

Dès qu'il est question de pointeur, utiliser les casts C++ (static_cast, reinterpret_cast), qui sont moins permissifs et donc moins dangereux (notamment, pour la const-correctness).

[hpfx]

Disons que le cast C-style est à bannir dès que l'un des deux types (source/destination) est un pointeur.
Il en est de même du cast function-style, qui n'est qu'un cast C-style déguisé.

Dès qu'il est question de pointeur, utiliser les casts C++ (static_cast, reinterpret_cast), qui sont moins permissifs et donc moins dangereux (notamment, pour la const-correctness).

mais justement est-ce que le fait qu'ils soient moins permissifs rajoute du code (et donc ralentie le code ?) surtout s'il 'y a pas de pointeur (type entier) et que donc ca revient un peu au même ?

quand je parle de ralentissement, c'est même si c'est inperspectible (comme des methodes "virtual") car je parle vraiment de section critique, et non pas du cas general.

[Matthieu Brucher]

Non, je t'ai dit que c'était la même chose, il n'y a pas de plus permissif ou pas dans le code. Une fois compilé, c'est strictement la même chose, sauf que pour le cast C, tu n'es pas certain du type de cast effectué.

[hpfx]

Non, je t'ai dit que c'était la même chose, il n'y a pas de plus permissif ou pas dans le code. Une fois compilé, c'est strictement la même chose, sauf que pour le cast C, tu n'es pas certain du type de cast effectué.

ben je suis prêt a utiliser le bouton résolu, si si ca fais des heures que j'hesite à le faire. mais il y a un truc dont je ne suis pas sur encore, c'est peu être juste une question de français a pres tout : dans la même phrase tu dis que c'est la même chose et que dans le cas du cast C on n'est pas certain du type de cast... ca aurait tendance a me faire dire que le code asm produit n'est pas identique.

voilà c'est juste que j'avais besoin d'être rassuré la dessus (oui je suis penible) : le code asm produit est identique dans les deux cas ?

Bon je viens d'essayer de comparer les deux, je vois juste que le md5 est different, mais j'y connais rien en decompilation, j'ai même pas les outils, donc je ne sais pas si cette difference est est vraiment du a ca. j'ai remis ce qu'il y avait avant et j'ai encore un autre md5, donc ce test ne veut absolument rien dire, a tout les coups il doit y avoir l'heure de compilation dans l'exe....
a noter que j'ai bien fait un rebuilt all pourtant avant.

[JulienDuSud]

C'est pareil pour ce qui est du résultat attendu, c'est différent pour ce qui est du comportement effectif, qui peut ne pas être celui attendu avec un cast "à la C". Les cast en C++ sont là pour préciser exactement le comportement que tu souhaites avoir. En C-style tu ne précises pas, donc tu t'exposes à ce qu'il ne fasse pas comme tu penses qu'il fera.

[Matthieu Brucher]

ben je suis prêt a utiliser le bouton résolu, si si ca fais des heures que j'hesite à le faire. mais il y a un truc dont je ne suis pas sur encore, c'est peu être juste une question de français a pres tout : dans la même phrase tu dis que c'est la même chose et que dans le cas du cast C on n'est pas certain du type de cast... ca aurait tendance a me faire dire que le code asm produit n'est pas identique.

Si c'est un transtypage static_cast, le code doit être quasiment identique. En revanche, avec le transtypage C, tu n'es pas sûr de ce qu'il va faire.