problème de cast

Bonjour,
J'aimerais caster un nombre entier en nombre flottant.
Je veux un cast qui conserve la signature du nombre, autrement dit que les 4 octets du nombre ne bougent pas.

Quand je fais un reinterpret_cast<float>( 0xFFFFFFFF), mon compilateur (gcc) me sort une erreur: invalid cast from type «unsigned int" to type «float"
Est-ce que quelqu'un a une piste?

Il faut passer par un cast de pointeurs:

En supposant que les deux types aient la même taille:
monUInt = *reinterpret_cast< unsigned int * >(&monFloat)
Et dans l'autre sens: monFloat = *reinterpret_cast< float * >(&monUInt)

Effectivement, ça marche, merci.
Mais je m'étonne que le reinterpret_cast ne sache pas convertir un int en float directement.

http://www.cppreference.com/keywords...pret_cast.html

puis relies ton message.

Salut Hypnocrate,

Si tu dois faire des aller-retours entre float et unsigned int, tu peux aussi utiliser une union:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

union BitPuree { unsigned int asInt; float asFloat; };   BitPuree myPuree; myPuree.asInt = 0xffffffff; float someOtherFloat = myPuree.asFloat; //... myPuree.asFloat = someProcessedFloat; unsigned int result = myPuree.asInt;

---

Carl

Citation:

---

Envoyé par 5hdumatin

Si tu dois faire des aller-retours entre float et unsigned int, tu peux aussi utiliser une union:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

union BitPuree { unsigned int asInt; float asFloat; };   BitPuree myPuree; myPuree.asInt = 0xffffffff; float someOtherFloat = myPuree.asFloat; //... myPuree.asFloat = someProcessedFloat; unsigned int result = myPuree.asInt;

---

---

Comportement indéfini, la manière correcte est d'utiliser memcpy.

Voe,

Citation:

---

Envoyé par corrector

Comportement indéfini, la manière correcte est d'utiliser memcpy.

---

Pourquoi comportement indéfini ?

Sous réserve que float et unsigned int aient la même taille, le comportement est précisément celui attendu.

Et le problème éventuellement posé si les tailles sont différentes se retrouvera lors de l'utilisation de memcpy.

oui de même taille sur certaines architectures... mais et le codage?

Citation:

---

Envoyé par droggo

Pourquoi comportement indéfini ?

---

Comportement indéfini parce que le membre de l'union que tu lis ne correspond pas à celui que tu as écris en dernier (et aucun des deux n'est une structure).

Citation:

---

Envoyé par droggo

Sous réserve que float et unsigned int aient la même taille, le comportement est précisément celui attendu.

---

Ah bon, où ce comportement est-il défini?

Dans la norme (pour un programme portable)?

Dans la doc de ton compilateur (pour un programme non-portable)?

Fei,

Citation:

---

Envoyé par corrector

Comportement indéfini parce que le membre de l'union que tu lis ne correspond pas à celui que tu as écris en dernier (et aucun des deux n'est une structure).

---

C'est exactement ce que tu obtiendrais en utilisant memcpy comme tu l'as proposé, et que ce soit une structure ou pas n'a rien à voir là-dedans.

Citation:

---

Envoyé par droggo

Fei,

C'est exactement ce que tu obtiendrais en utilisant memcpy comme tu l'as proposé, et que ce soit une structure ou pas n'a rien à voir là-dedans.

---

Tu es sûr? Pourquoi le comportement serait indéfini?

Et comment éviter le comportement indéfini alors?

Citation:

---

Envoyé par droggo

C'est exactement ce que tu obtiendrais en utilisant memcpy comme tu l'as proposé, et que ce soit une structure ou pas n'a rien à voir là-dedans.

---

Pas sûr. J'ai pas été faire une exégèse mais à mon avis la lecture d'un champs autre que le dernier écrit d'une union me semble être un comportement indéfini même dans le cas où les deux champs sont de même type tandis que le résultat de memcpy n'est du comportement indéfini que une lecture a lieu par après et si le motif de bits écrits n'est pas un motif valide pour le type lu (raisonnement: un memcpy vers un tableau d'unsigned char est bien défini, un memcpy depuis un tel tableau l'est aussi si le motif de bits copié est un motif valide et je ne vois pas de raison pour laquelle avoir la source d'un autre type poserait problème).

En passant, corrector, tu as une partie de la réponse que je ne t'ai jamais donnée sur la manière d'utiliser de manière conforme certaines garanties en matière de représentation.

Fio,

Citation:

---

Envoyé par Jean-Marc.Bourguet

Pas sûr. J'ai pas été faire une exégèse mais à mon avis la lecture d'un champs autre que le dernier écrit d'une union me semble être un comportement indéfini même dans le cas où les deux champs sont de même type tandis que le résultat de memcpy n'est du comportement indéfini que une lecture a lieu par après et si le motif de bits écrits n'est pas un motif valide pour le type lu (raisonnement: un memcpy vers un tableau d'unsigned char est bien défini, un memcpy depuis un tel tableau l'est aussi si le motif de bits copié est un motif valide et je ne vois pas de raison pour laquelle avoir la source d'un autre type poserait problème).

En passant, corrector, tu as une partie de la réponse que je ne t'ai jamais donnée sur la manière d'utiliser de manière conforme certaines garanties en matière de représentation.

---

Dans le cas dont nous parlons, c'est exactement équivalent à copier les données brutes d'une variable à l'autre avec memcpy, et c'est également strictement équivalent (quant au résultat) à la méthode proposée par Medinoc, qui est celle que je préfère :

Citation:

---

Envoyé par Médinoc

Il faut passer par un cast de pointeurs:
En supposant que les deux types aient la même taille:
monUInt = *reinterpret_cast< unsigned int * >(&monFloat)
Et dans l'autre sens: monFloat = *reinterpret_cast< float * >(&monUInt)

---

à quoi la réponse a été

Citation:

---

Envoyé par Hypnocrate

Effectivement, ça marche, merci.
Mais je m'étonne que le reinterpret_cast ne sache pas convertir un int en float directement.

---

Dans tous les cas, il faudrait pouvoir garantir que toute valeur binaire valide pour un des types l'est aussi pour l'autre, ce qui n'est d'ailleurs pas le cas entre un unsigned int et un float, puisque on risque de tomber sur des NAN et autres choses.
Mais la question était un cast entre ces 2 types, ce n'est pas à moi de décider de sa validité.

Citation:

---

Envoyé par corrector

Comportement indéfini, la manière correcte est d'utiliser memcpy.

---

Après réflexion, bien que le code fonctionne en pratique, je crois qu'effectivement le comportement est indéfini d'après le standard (pas lu, mais cela me rappelle bien quelque chose). Au temps pour moi.

Carl

Citation:

---

Envoyé par Hypnocrate

Mais je m'étonne que le reinterpret_cast ne sache pas convertir un int en float directement.

---

Pourquoi? Tu ne peux pas non plus écrire :

Code:

---

1 2	const int ci = 3; int i = const_cast<int> (ci);

---

ni

Code:

---

1 2 3 4 5

class Base { virtual ~Base(); }; class Derived : public Base {};   Base b; Derived d = static_cast<Derived> (b);

---

ni

Code:

---

Derived d = dynamic_cast<Derived> (b);

---

Citation:

---

Envoyé par droggo

la méthode proposée par Medinoc, qui est celle que je préfère :

---

Le comportement est indéfini à cause de :

Citation:

---

Envoyé par N2315, 3.10 Lvalues and rvalues [basic.lval]/15

If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined

• the dynamic type of the object,
• a cv-qualified version of the dynamic type of the object,
• a type similar (as defined in 4.4) to the dynamic type of the object,
• a type that is the signed or unsigned type corresponding to the dynamic type of the object,
• a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,
• an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union),
• a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
• a char or unsigned char type.

---

On accède à un unsigned int par un float, et ça n'est clairement pas un des cas de la liste.

Le comportement est encore plus indéfini parce qu'il n'y a rien qui t'indiques ce que vaut le résultat de reinterpret_cast, et si cette valeur est déréférençable.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Pas sûr. J'ai pas été faire une exégèse mais à mon avis la lecture d'un champs autre que le dernier écrit d'une union me semble être un comportement indéfini même dans le cas où les deux champs sont de même type

---

Là, j'ai du mal à te suivre :

Code:

---

1 2 3 4 5 6

union { int a, b; } u; int *pa = &u.a, *pb = &u.b; *pa = 1; cout << *pb;

---

Est-ce que ce code a un comportement indéfini? Pourtant pa = pb!

Citation:

---

Envoyé par droggo

Dans le cas dont nous parlons, c'est exactement équivalent à copier les données brutes d'une variable à l'autre avec memcpy,

---

Référence?

Le problème n'est pas la représentation en mémoire ou un formalisme poussé à l'absurde, c'est savoir que ce que les optimiseurs peuvent se permettre de faire. Mon expérience est qu'ils utilisent de plus en plus ce genre de liberté.

Citation:

---

et c'est également strictement équivalent (quant au résultat) à la méthode proposée par Medinoc, qui est celle que je préfère:

à quoi la réponse a été

Citation:

---

Ca marche

---

---

Ca marche ici et maintenant n'a jamais, en C++, été le moindre commencement de preuve que c'est sensé marcher.

Citation:

---

Envoyé par corrector

Là, j'ai du mal à te suivre :

Code:

---

1 2 3 4 5 6

union { int a, b; } u; int *pa = &u.a, *pb = &u.b; *pa = 1; cout << *pb;

---

Est-ce que ce code a un comportement indéfini? Pourtant pa = pb!

---

Non, mais je crois que

Code:

---

1 2	u.a = 1; cout << u.b;

---

en a bien un.

Ca va naturellement fonctionner comme on le désire jusqu'au moment où il y en a un qui remarque que prendre en compte que u.a et u.b ne peuvent pas être des alias et les assigner à des registres différents permet de gagner 10% sur un des benchs de SPEC.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Le problème n'est pas la représentation en mémoire ou un formalisme poussé à l'absurde,

---

un formalisme poussé à l'absurde me permettrait de raisonner sur les programmes, et de me convaincre de certaines choses sans hand-waving intensif.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Non, mais je crois que

Code:

---

1 2	u.a = 1; cout << u.b;

---

en a bien un.

---

Mais pour moi ils sont exactement équivalents! (Là je suis perdu.)

Ou alors je ne saisis pas la sémantique des pointeurs sur membres d'union. (On dirait que les unions sont définies dans un langage qui n'a pas de pointeurs.)

En plus, j'étais en train de me dire que mon argument pa = pb ne tenait pas, pa et pb ne sont pas intentionnellement équivalents, comme &x[0][1]+1 et &x[1][0] (pour 'int x[2][2];'). (J'allais poster une note à ce sujet... à l'instant.)

Citation:

---

Envoyé par Jean-Marc.Bourguet

Ca va naturellement fonctionner comme on le désire jusqu'au moment où il y en a un qui remarque que prendre en compte que u.a et u.b ne peuvent pas être des alias et les assigner à des registres différents permet de gagner 10% sur un des benchs de SPEC.

---

Et après ça va râler pendant des mois sur la mailing-list.

Citation:

---

Envoyé par corrector

un formalisme poussé à l'absurde me permettrait de raisonner sur les programmes, et de me convaincre de certaines choses sans hand-waving intensif.

---

Si tu veux plus de rigueur, tu sais où trouver les langages qui l'offrent.

Citation:

---

Mais pour moi ils sont exactement équivalents! (Là je suis perdu.)

---

Pour argumenter réellement, il faudrait que je retourne voir précisément les textes, parce qu'ici je raisonne plus sur le modèle que je me suis construit que sur les textes -- et mon modèle a volontairement tendance à être trop prudent.

Citation:

---

Ou alors je ne saisis pas la sémantique des pointeurs sur membres d'union. (On dirait que les unions sont définies dans un langage qui n'a pas de pointeurs.)

---

Le problème est plutôt que le modèle dont le C++ a hérité du C hésite entre deux niveaux d'abstractions.

Citation:

---

Et après ça va râler pendant des mois sur la mailing-list.

---

Ce n'est pas l'activité sur les mailing lists qui me gène, c'est le temps passé à trouver la source d'un problème qui n'apparait que dans la version optimisée sur la plateforme la moins utilisée.

Fio,

Citation:

---

Envoyé par 5hdumatin

Après réflexion, bien que le code fonctionne en pratique, je crois qu'effectivement le comportement est indéfini d'après le standard (pas lu, mais cela me rappelle bien quelque chose). Au temps pour moi.

Carl

---

C'est vrai au sens général, mais puisqu'on sait ce qu'on veut faire, interpréter les données d'un unsigned int comme si c'était un float, le comportement est parfaitement défini. :)

Citation:

---

Envoyé par droggo

C'est vrai au sens général, mais puisqu'on sait ce qu'on veut faire, interpréter les données d'un unsigned int comme si c'était un float, le comportement est parfaitement défini. :)

---

Je me range un peu à l'avis de Jean-Marc: à mon avis, ça fonctionnera toujours sans aucune optimisation, mais vu que les compilateurs optimisent de plus en plus agressivement, il est possible qu'ils finissent par faire capoter ce genre d'astuces. A moins d'utiliser "volatile"?

Corrector, Jean-Marc, quelle serait alors selon vous (je ne connais pas assez bien le standard) la façon correcte et conforme au standard pour faire ce type de cast? Car pour l'instant nous n'avons répondu que par la négative...

Carl

Citation:

---

Envoyé par 5hdumatin

Corrector, Jean-Marc, quelle serait alors selon vous (je ne connais pas assez bien le standard) la façon correcte et conforme au standard pour faire ce type de cast? Car pour l'instant nous n'avons répondu que par la négative...

---

Dans ma perception de risque croissant:
- memcpy
- reinterpret_cast<T*>
- union

Je ne vois pas de raisons pour faire foirer la première méthode si interpréter les bits comme l'autre type a du sens.

La deuxième va poser des problèmes si les contraintes d'alignement sont différentes entre les deux types, mais à part cela je ne vois pas non plus de raison de casser cela.

La troisième n'a pas ce problème, mais est celle qui risque le plus de n'être pas supportée; mais il ne fait pas exagérer non plus les risques, la technique est tellement commune qu'il va avoir de la pression des utilisateurs pour être supportée.

Foe,

Citation:

---

Envoyé par Jean-Marc.Bourguet

La troisième n'a pas ce problème, mais est celle qui risque le plus de n'être pas supportée; mais il ne fait pas exagérer non plus les risques, la technique est tellement commune qu'il va avoir de la pression des utilisateurs pour être supportée.

---

Je ne vois pas quel pourrait être le problème dû à une optimisation : si on met des données dans une union, qui est une variable comme une autre, et qu'elles ne sont plus valides lorqu'on veut s'en servir, il faudra sérieusement penser à changer de compilateur.

Si les concepteurs de compilateurs en arrivent à faire de telles "optimisations", qui compromettent le fonctionnement d'un programme, il faudra également penser à leur expliquer qu'optimiser, c'est bien, mais qu'il faut réfléchir un peu avant de se permettre certaines choses.

Citation:

---

Envoyé par droggo

Je ne vois pas quel pourrait être le problème dû à une optimisation : si on met des données dans une union, qui est une variable comme une autre, et qu'elles ne sont plus valides lorqu'on veut s'en servir, il faudra sérieusement penser à changer de compilateur.

---

Si tu mets ta donnée dans un membre de l'union et que te relis ce même membre tout ira bien (une variable comme une autre).

Si tu te sers d'une union pour éviter d'écrire reinterpret_cast, c'est à dire si tu mets ta donnée dans un membre, et que lis un autre membre (en l'occurrence, d'un autre type), tu n'utilises pas une union pour ce pour quoi elle est faite, et, selon la structure précise de ton code et le compilateur, tu pourrais ne pas obtenir ce que veux.

Citation:

---

Envoyé par droggo

Si les concepteurs de compilateurs en arrivent à faire de telles "optimisations", qui compromettent le fonctionnement d'un programme, il faudra également penser à leur expliquer qu'optimiser, c'est bien, mais qu'il faut réfléchir un peu avant de se permettre certaines choses.

---

Quand gcc a commencé a simplifier agressivement les expressions arithmétiques, pour simplifier certains tests :

Code:

---

1 2 3 4

void foo (int a) { if (a + 1000 < a) overflow (); }

---

Quand gcc a décidé que a + 1000 n'était pas strictement inférieur à a, par définition, et que donc la fonction foo ne faisait jamais rien, certaines personnes ont essayé d'expliquer qu'"optimiser c'était bien", mais que là ça allait trop loin, tout ça.

Ce à quoi il leur a été répondu qu'ils n'avaient qu'à apprendre à programmer correctement. (Avec quand même une distinction faite entre le vieux code hérité de quelqu'un d'autre, et le fait d'écrire de telles choses.)

Au final, gcc optimise de telles expressions, entre autres choses.

Et les protestations du genre "il faut réfléchir un peu avant de se permettre certaines choses" ne risquent pas d'impressionner beaucoup les développeurs du compilateur. Si tu veux défendre ton point de vue, tu as intérêt à développer des arguments autrement mieux étayés.

Citation:

---

Envoyé par droggo

Si les concepteurs de compilateurs en arrivent à faire de telles "optimisations", qui compromettent le fonctionnement d'un programme, il faudra également penser à leur expliquer qu'optimiser, c'est bien, mais qu'il faut réfléchir un peu avant de se permettre certaines choses.

---

On a vu des compilateurs qui ne compilaient correctement que les tests de SPEC et faire des choses bizarres simplement pour ameliorer leur perfs a ce benchmark. Quand les performances sont un argument de vente -- et ce l'est pour les compilateurs comme pour les processeurs, ce n'est pas un hasard que les fabriquants des derniers soient impliques dans le developpement des premiers; Intel, IBM et Sun pour n'en citer que trois sponsorisent pas mal le developpement de gcc alors qu'ils ont leurs propres compilateurs -- il ne faut pas s'etonner que les gens qui travaillent sur l'optimisation utilisent tous les degres de liberte dont ils disposent.