Discussion :

[Hypnocrate]

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?

[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)

[Hypnocrate]

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

[reptils]

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

puis relies ton message.

[Invité]

Salut Hypnocrate,

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

Code :

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

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

[corrector]

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

Code :

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

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.

[droggo]

Voe,

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.

[reptils]

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

[corrector]

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).

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)?

[droggo]

Fei,

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.

[corrector]

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?

[Jean-Marc.Bourguet]

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.

[droggo]

Fio,

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 :

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é

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é.

[Invité]

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

[corrector]

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 :

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

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

ni

Code :

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

1
2
3
4
5
class Base { virtual ~Base(); };
class Derived : public Base {};
 
Base b;
Derived d = static_cast<Derived> (b);

ni

Code :

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

Derived d = dynamic_cast<Derived> (b);

[corrector]

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

Le comportement est indéfini à cause de :

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.

[corrector]

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 :

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

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!

[Jean-Marc.Bourguet]

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é.

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é

Ca marche

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

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

Code :

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

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 :

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

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.

[corrector]

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.

Non, mais je crois que

Code :

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

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.)

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.

[Jean-Marc.Bourguet]

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.

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.

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.

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.