probleme avec typedef

Version imprimable

salut les gas
une petite question a propos du typedef :cry:
voila le code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 typedef unsigned __int32 uint32; typedef unsigned __int64 uint64; double uint64_to_double (const uint64 x) { // Petit hack pour convertir du 64 bits en double // Ce hack dépend de l'endian (ici ça marche sur Intel x86) typedef uint32 uint64_32[2]; uint64_32 *hack = (uint64_32 *)&x; double dbl; dbl = (*hack)[1]; dbl *= 4294967296; dbl += (*hack)[0]; return dbl; }
comme il est indiqué c'est une fonction qui permet de convertir un unint64 en Double
mais ce que je n'arrive pas à comprendre c'est les deux ligne suivante
Code:

1 2 3 typedef uint32 uint64_32[2]; uint64_32 *hack = (uint64_32 *)&x;
j'ai essayé de chercher sur internet mais j'ai pas trouver une écriture simulaire à

Code:

uint64_32 *hack

si quelqu'un peut juste m'indiquer un lien d'un cours ou le fonctionnement de ce typedef
merci encore une fois les gas

07/07/2011, 08h18
Sve@r
Citation:
Envoyé par nR.mEcs0ft

mais ce que je n'arrive pas à comprendre c'est les deux ligne suivante

Code:

1 2 3 typedef uint32 uint64_32[2]; uint64_32 *hack = (uint64_32 *)&x;
Salut

Ces lignes récupèrent l'adresse de x dans un pointeur uint64_32. Par la suite, chaque fois que tu utiliseras le pointé, le compilo considèrera l'élément pointé comme un uint64_32

Citation:

Envoyé par nR.mEcs0ft

j'ai essayé de chercher sur internet mais j'ai pas trouver une écriture similaire à

Code:

uint64_32 *hack

Bah, c'est comme déclarer un FILE *hack. Un pointeur quoi.

Citation:

Envoyé par nR.mEcs0ft

si quelqu'un peut juste m'indiquer un lien d'un cours ou le fonctionnement de ce typedef

Celui-ci comme les autres définit un alias sur un nouveau type à partir d'un type existant

Citation:

Envoyé par nR.mEcs0ft

merci encore une fois les gars

Pfff, quelle orthographe !!!
07/07/2011, 12h11
nR.mEcs0ft

Salut
merci Sve@r pour la réponse
désoler pour l'orthographe:lol: j'ai pas fait attention
bon

Citation:

Ces lignes récupèrent l'adresse de x dans un pointeur uint64_32. Par la suite, chaque fois que tu utiliseras le pointé, le compilo considèrera l'élément pointé comme un uint64_32

oui ça je le sais déjà mais pour moi avec la ligne

Code:

typedef uint32 uint64_32[2];

un uint64_32 u1;
est équivalant à uint64_32 u1[2]
n'est ce pas ????
si c'est vrai . que veut dire :

Code:

uint64_32 *hack;

un pointeur sur un vecteur de deux éléments de type uint64_32 ??:calim2:
car le compilateur me déclare qui est de type

Code:

uint64_32[2] *

et les hack[0] ,hack[1] de type uint64_32 (unsigned int) ???
si c'est vrai encore une petite question (bête) pourquoi dans

Code:

uint64_32 *hack = (uint64_32 *)&x;

il y a un '&' + un cast en uint64_32 * ??

une autre chose
quand je vérifie le contenu du hack[0] oui il a comme valeur celle de x mais hack[1] il a 0
quand je remplace le x par un i par exemple de type int le hack[0] a la valeur de i,mais le hack[1] a une valeur aléatoire breff je crois que j'ai pas bien compris le

Code:

uint64_32 *hack = (uint64_32 *)&x;

est ce qu'il a un effet sur hack[0] et hack[1]
un unsigned int [2] * qui pointe sur un unsigned int :roll: ??? :cry:
merciii encore les gars:ccool:
07/07/2011, 18h49
Sve@r

Citation:

Envoyé par nR.mEcs0ft

oui ça je le sais déjà mais pour moi avec la ligne

Code:

typedef uint32 uint64_32[2];

un uint64_32 u1;
est équivalant à uint64_32 u1[2]
n'est ce pas ????

Exact

Citation:

Envoyé par nR.mEcs0ft

si c'est vrai . que veut dire :

Code:

uint64_32 *hack;

un pointeur sur un vecteur de deux éléments de type uint64_32 ??:calim2:
car le compilateur me déclare qui est de type

Code:

uint64_32[2] *

Encore exact

Citation:

Envoyé par nR.mEcs0ft

et les hack[0] ,hack[1] de type uint64_32 (unsigned int) ???

Encore exact. Et en plus chacun d'eux contient la moitié d'un uint64_32

Citation:

Envoyé par nR.mEcs0ft

si c'est vrai encore une petite question (bête) pourquoi dans

Code:

uint64_32 *hack = (uint64_32 *)&x;

il y a un '&' + un cast en uint64_32 * ??

&x => l'adresse de x (qui est de type "pointeur sur uint64")
(uint64_32*)&x => cette adresse est convertie en adresse de type "pointeur sur uint64_32"

Citation:

Envoyé par nR.mEcs0ft

une autre chose
quand je vérifie le contenu du hack[0] oui il a comme valeur celle de x mais hack[1] il a 0

Probablement parce que x est trop petit pour remplir les 64 bits. Essaye de mettre x=(0xffffffff * 4)

Citation:

Envoyé par nR.mEcs0ft

quand je remplace le x par un i par exemple de type int le hack[0] a la valeur de i,mais le hack[1] a une valeur aléatoire

Là aussi c'est normal. Un int ne remplit que 32 bits mais il se trouve quelque part dans la mémoire (mémoire qui englobe toutes les variables). Donc avant lui il y a quelque chose (peut-être une variable "toto") et après lui il y a autre chose (une variable "titi").
Ensuite, tu écris *hack=(uint64_32 *)&i ce qui signifie "considère maintenant l'adresse de i (copiée dans hack) comme l'adresse d'une zone de 64 bits". Partant de là, quand tu affiches hack[0] tu affiches les 32 bits de i et quand tu affiches hack[1] tu affiches les 32 bits de la zone qui suit i (les bits de titi).

Citation:

Envoyé par nR.mEcs0ft

merciii encore les gars:ccool:

Pas de pb. :ccool:
07/07/2011, 18h57
diogene
Citation:

un uint64_32 u1 est équivalent à uint64_32 u1[2]

non, à uint32 u1[2]

Citation:

si c'est vrai . que veut dire :
uint64_32 *hack;
un pointeur sur un vecteur de deux éléments de type uint64_32 ??

Non, un pointeur sur un tableau de 2 uint32. Autrement dit, c'est équivalent à uint32 (*hack)[2]

Citation:

le compilateur me déclare qui est de type uint64_32[2] *

?? Il est du type uint32[2] *

Citation:

et les hack[0] ,hack[1] de type uint64_32 (unsigned int) ???

oui hack[0] ,hack[1] sont des uint64_32 (comme *hack ) et (*hack)[0] et (*hack)[1] sont des uint32

Citation:

je crois que j'ai pas bien compris le uint64_32 *hack = (uint64_32 *)&x;

C'est un cast sauvage : &x n'est pas un uint64_32 * mais un const uint64 *. Le but de ce cast est de permettre d'utiliser x non pas comme un uint64 (qu'il est) mais comme un tableau de 2 uint32 (un uint64_32)

Ce code revient à (cet uint64_32 ne fait qu'obscurcir les choses)
Code:

1 2 3 4 5 6 7 8 9 double uint64_to_double (const uint64 x) { uint32 (*hack)[2] = (uint32 (*)[2])&x; double dbl; dbl = (*hack)[1]; dbl *= 4294967296; dbl += (*hack)[0]; return dbl; }
ou, puisqu'on est avec des cast sauvages, autant en profiter :
Code:

1 2 3 4 5 6 7 8 9 double uint64_to_double (const uint64 x) { uint32 *hack = (uint32 *)&x; double dbl; dbl = hack[1]; dbl *= 4294967296; dbl += hack[0]; return dbl; }
Remarque : pourquoi ne pas avoir simplement
Code:

1 2 3 uint64 a = 1234567890123456; // double x = uint64_to_double(a); double x = a;
08/07/2011, 15h47
nR.mEcs0ft

Citation:

Remarque : pourquoi ne pas avoir simplement

oui moi aussi je ne sais pas pourquoi , mais d'aprés le code il y a un

Code:

#if defined(_MSC_VER)

donc visual studio ne cast pas de uint64 en double
voila le lien du code
http://haypo.developpez.com/article/...requence_cpu.c

le code sert a calculer le fréquence du Processeur et du Conteur windows .
désoler pour les uint64_32 ;
oui tu a raisons il sont des uint32 ,j'ai mélangé les choses un peu :oops: