reintepret_cast <unsigned int> (float)

Version imprimable

19/01/2018, 12h25
Bktero

reintepret_cast <unsigned int> (float)
Bonjour,

Prenons ce bout de code dont le but est d'afficher les bits d'un flottant :
Code:

1 2 3 4 5 int main() { float value = 1.0f; auto integer = reinterpret_cast<std::uint32_t&>(value); std::cout << std::bitset<32>(integer) << std::endl; }
Pourquoi est-il nécessaire de mettre un & dans le cast, sous peine d'obtenir l'erreur suivante ?
```
error: invalid cast from type 'float' to type 'uint32_t {aka unsigned int}'
```
Question secondaire : est-ce que ma technique d'affichage des bits est correcte ? Y a t-il mieux ?

Merci d'avance ! :ccool:
19/01/2018, 14h39
Bousk
Salut,

je ne saurais dire pourquoi, mais généralement pour effectuer une conversion avec reinterpret_cast vaut mieux utiliser des pointeurs que je trouve plus clairs auto i = *reinterpret_cast<uint32_t*>(&monfloat);.
Mais si je veux afficher les bits d'un truc, j'utiliserai plutôt un code de ce genre
Code:

1 2 3 4 #define GETBIT(o, b) (o & (1<<(b)) ? 1 : 0) std::cout<<"0b"; for (int i = 0; i < sizeof(monfloat) * 8; ++i) std::cout<<GETBIT(monfloat, i);
19/01/2018, 16h13
prgasp77

Bonjour,

TL; DR: les deux versions du cast sont illégales. Mais dans le second cas, il s'agit d'UB "no diagnostic required".

Cast d'un float en entier

Code:

reinterpret_cast<std::uint32_t>(value);

Dans ce cas, il s'agit d'une mauvaise utilisation de reinterpret_cast :

Citation:

[expr.reinterpret.cast]/1

Conversions that can be performed explicitly using reinterpret_cast are listed below.
No other conversion can be performed explicitly using reinterpret_cast.

Les points [expr.reinterpret.cast]/2 à [expr.reinterpret.cast]/11 listent exhaustivement les usages possibles de reinterpret_cast, et float vers entier n'en fait pas parti.

Cast d'une référence vers un float en référence vers un entier

Code:

reinterpret_cast<std::uint32_t&>(value);

Dans ce cas, il s'agit d'une violation de la strict aliasing rule :

Citation:

[basic.lval]/11

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

Les points [basic.lval]/11.1 à [basic.lval]/11.8 listent exhaustivement les cas possibles, et l'interprétation d'un type float par un type entier n'en fait pas parti.

Pourquoi dans le second cas ça marche alors ?
C'est ce qu'il y a de plus diabolique avec l'undefined behavior.

Citation:

[defns.undefined]
undefined behavior

behavior for which this document imposes no requirements

Dans un tel cas, tout peut arriver : il s'agit d'une construction erronée ou non portable d'un programme pour lequel le standard n'impose aucune restriction (notamment, la compilation peut réussir) pour l'implémentation (le compilateur). Le résultat peut varier : la situation peut être complètement ignorée, le programme peut avoir un comportement inatendu ou aléatoire, vous pourriez même voir des démons sortir de vos trous de nez !

La conclusion est laissée au soin du lecteur.

Du coup, comment faire ?

Afin de construire un bitset à partir d'un flotant, et cela d'une manière portable et bien définie, il vous faut :

vous assurer de travailler avec des types compatibles ;
copier la représentation de votre flotant dans un type entier compatible ;
construire le bitset à partir de cet entier.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 #include <bitset> #include <cstring> #include <iostream> int main() { float f = -1./0.; static_assert(sizeof(float) <= sizeof(long long unsigned int), "wrong sizes"); // 1. long long unsigned int f_as_int = 0; std::memcpy(&f_as_int, &f, sizeof(float)); // 2. std::bitset<8*sizeof(float)> f_as_bitset{f_as_int}; // 3. std::cout << f_as_bitset.to_string() << "\n"; }.
Affiche 11111111100000000000000000000000. Live démo : http://coliru.stacked-crooked.com/a/b5309c227a823f1d

19/01/2018, 16h26
Bousk

Tu as aussi cet article qui traite de sérialisation de float avec l'astuce de l'union et pourrait t'être utile.
D'autres informations encore ici https://jeux.developpez.com/tutoriel...ule-flottante/
19/01/2018, 16h30
prgasp77

Citation:

Envoyé par Bousk

Tu as aussi cet article qui traite de sérialisation de float avec l'astuce de l'union et pourrait t'être utile.

Attention, le "truc avec l'union" est aussi UB.

Par contre, dans mon souvenir, le cast en unsigned char* est valide.
La taille de l'ensemble à parcourir est sizeof(T).
Code:

1 2 3 4 5 6 int main() { float value = 1.0f; auto p = reinterpret_cast<unsigned char*>(&value); for (std::size_t i = 0; i < sizeof(value); ++i) std::cout << *p; std::cout << std::endl; }
On parle d'aliasing de types.

19/01/2018, 16h50
prgasp77

Citation:

Envoyé par ternel

Par contre, dans mon souvenir, le cast en unsigned char* est valide.

Tout à fait :plusser: ! Mais il n'est ensuite pas possible de construire un bitset.
19/01/2018, 17h43
Bousk

Citation:

Envoyé par prgasp77

Attention, le "truc avec l'union" est aussi UB.

Oui et tout est précisé dans l'article, ça marche pour tous les compilateurs qu'il a utilisé. Ca marche aussi pour tous les compilateurs que j'ai utilisé.

Citation:

Vous pouvez aussi y parvenir via un uint32_t*, mais d'expérience ça ne passe pas avec GCC -O2, donc je préfère la technique de l'union à la place. Des amis ont aussi fait remarquer (à juste titre) que le seul moyen absolument standard d'avoir le flottant comme entier est de convertir un pointeur vers le flottant en uint8_t* et reconstruire la valeur entière depuis les valeurs des quatre octets accédés individuellement via un pointeur d'octet. Ça semble une manière un peu absurde de le faire selon moi. Mesdames et messieurs… C++ !

En attendant, ces cinq dernières années, je n'ai eu aucun problème avec la technique de l'union.

Un UB n'est pas un truc magique qui ne marche pas ou à fuir comme la peste. Un moment faut écrire du code que le compilateur comprend, parce que le code est de toutes façons rarement/jamais portés sur énormément de compilos mais sur un ensemble fini et connus.
19/01/2018, 17h49
Médinoc

Citation:

Envoyé par prgasp77

Attention, le "truc avec l'union" est aussi UB.

Je suis surpris que le memcpy() ne le soit pas.
Pour faire ça bien, j'utiliserais les unsigned char pour construire l'entier.

A-t-on, depuis le temps, des macros standard pour l'endianness, ou faut-il la tester en runtime (là encore, avec la méthode du unsigned char)?
19/01/2018, 17h52
prgasp77

Citation:

Je suis surpris que le memcpy() ne le soit pas.

Non c'est tout bon !

Citation:

-t-on, depuis le temps, des macros standard pour l'endianness, ou faut-il la tester en runtime (là encore, avec la méthode du unsigned char)?

Des solutions arrivent avec C++20 :)
19/01/2018, 17h59
prgasp77

Citation:

Envoyé par Bousk

Un UB n'est pas un truc magique qui ne marche pas ou à fuir comme la peste. Un moment faut écrire du code que le compilateur comprend, parce que le code est de toutes façons rarement/jamais portés sur énormément de compilos mais sur un ensemble fini et connus.

J'ai déjà perdu tellement de temps dans ma vie avec des UB, notamment suite à du portage de code d'un compilo à sa version suivante ... ou comment un apt update peut casser votre programme. J'ai déjà perdu suffisamment de temps pour toute une vie, si je peux éviter l'UB en écrivant une ligne de plus, je le fais.
19/01/2018, 21h47
Médinoc

Citation:

Envoyé par Bousk

Un UB n'est pas un truc magique qui ne marche pas ou à fuir comme la peste. Un moment faut écrire du code que le compilateur comprend, parce que le code est de toutes façons rarement/jamais portés sur énormément de compilos mais sur un ensemble fini et connus.

Le problème c'est que de nos jours, quand le compilo détecte un UB, il décide que ça n'arrivera jamais et optimise comme un porc en conséquence. Ce qui veut dire que plus un compilo est récent, plus le UB est dangereux.

J'avais lu un exemple où quelqu'un avait joué avec les casts pour avoir des références potentiellement nulles (ce qui est un UB) et avait mis un test de nullité dans une fonction: void myfunc(int &x) { if(&x!=NULL) { x=42; } }Le compilo a décidé qu'une référence nulle étant un UB, ça n'arrivait jamais donc le test était inutile...
Moralité: Les compilos de nos jours sont optimisés pour te renvoyer les UB dans la gueule, donc ne fais pas de UB...

Et au passage, garde à l'esprit que les entiers signés ont beaucoup plus de UB que les non-signés.
20/01/2018, 17h42
dalfab

Bonjour,

Sur un des processeurs que j'utilise, les exemples cités qui fonctionnent sont ceux de Bktero et de ternel. Les union fonctionnent aussi.
Un indice, vues les capacités du MSP320 on a forcément sizeof(char)==sizeof(int).
22/01/2018, 14h32
koala01

Salut,

Citation:

Envoyé par dalfab

Bonjour,

Sur un des processeurs que j'utilise, les exemples cités qui fonctionnent sont ceux de Bktero et de ternel. Les union fonctionnent aussi.
Un indice, vues les capacités du MSP320 on a forcément sizeof(char)==sizeof(int).

Tu es peut-être dans cette situation, mais tu devrais faire comme si ce n'était pas le cas, car la norme précise bien que sizeof(char) <= sizeof(short) <= sizeof(int)...

Partir sur une hypothèse différente -- fut-elle vérifiée aujourd'hui sur ton processeur actuel, avec ton compilateur actuel -- t'expose à des problèmes sans noms lorsque tu passeras à "la version suivante" du processeur ou du compilateur.

Et il suffit de "pas grand chose" pour que cela arrive: tôt ou tard, il y aura rupture de stock (ne serait-ce que parce que la machine qui le construit sera tombée en panne) du processeur que tu utilises, et ton fournisseur t'enverra la version suivante (il te préviendra sans doute, du moins, on peut l'espérer :D ) !
22/01/2018, 20h29
dalfab

Mon compilateur est tout à fait conforme à la norme sizeof(char)<=sizeof(short)<=sizeof(int) et un int doit pouvoir stocker [-32767,+32767]. Il n'y a aucun problème particulier si on n'oublie pas qu'un byte peut tout à fait faire 2 octets, le MSP320 ne peut accéder qu'à 65536 mots donc on a aussi sizeof(void*)==sizeof(char) et sizeof(long)==sizeof(float)==2.
23/01/2018, 01h32
koala01

Je n'ai jamais voulu dire que le compilateur que tu utilisais n'était pas conforme à la norme, car, à partir du moment où l'opérateur de comparaison est <= et non simplement <, il va de soi que l'on peut se trouver dans une situation dans laquelle sizeof(char) == sizeof(short) et sizeof(short) == sizeof(int) (et, partant, du fait de la transitivité de l'égalité, dans laquelle sizeof(char) == sizeof(int) ).

Seulement, c'est une situation tout à fait particulière due à une configuration matérielle donnée qui est loin d'être vérifiée de manière systématique.

Et donc, si tu pars du principe que se sera systématique, tu te mets de facto dans une faiblesse par rapport à n'importe quelle décision de "faire autrement" qui pourrait être prise, car tout ce qui sera basé sur cette assertion deviendra forcément caduque.

Et, comme tu n'as -- a priori -- aucun droit de regard sur ce genre de décision, tu cours le risque qu'elle soit prise... à peu près n'importe quand. Mais tu peux avoir la certitude que ce sera toujours... au plus mauvais moment pour toi ;)
23/01/2018, 07h29
Médinoc

Tant qu'on parle de l'adhérence stricte à ce genre de standards, là où ça fait mal, c'est qu'apparemment il a fallu attendre plusieurs normes avant d'avoir la garantie que INT_MIN <= -INT_MAX (et donc, la garantie que -INT_MAX est une valeur valide).