Voila ce que je cherche à faire :
inverser la partie haute et la partie passe d'un long.
Donc : passer les 4 premier octets en dernier et les 4 derniers en 1er. De sorte que 0xAB802453 devienne 0x2453AB80 (c pour un codage).
J'extrait la partie haut et la partie basse de mon long de la façon suivante :

>>    return (lHighPart & lLowPart);
 
ça devrait être un | ...
 
ensuite, tu décales les parties de 16 bits chacune dans un sens :
 
long lHighPart = (_l & 0xFFFF0000) >> 16;  
long lLowPart  = (_l & 0x0000FFFF) << 16;  

manque peut etre le decalage
 
Edit : Ce qui devrait donner  
 

en espérant que tes long sont evidemment sur 32bits

 
Sous Win32, c'est forcément sur 32 bits un long je crois !

Merci.
qd même j'arrive pas à comprendre pourquoi il faut décaler, pour la partie basse. Pour la partie haute je trouve ça logique, ms pr la partie basse g du mal. Enfin bref, merci beaucoup.

ben parce que sinon tu vas avoir toute ton infos sur les 16 mêmes bits, et quand tu vas appliquer le | tu vas un peu perdre tout ca...

 
Ouais, mais le décalage de la partie haute devrait suffire.
comme j'ai fait ici :
http://forum.hardware.fr/forum2.ph [...] t=#t267915

Du coup, mon truc est presque bon !? il faudrais que je fasse comme ça, c ça ?

transformer 0x12345678 en 0x56781234  
 
hi = 0x12345678 & ffff0000
hi = 0x12340000
 
lo = 0x12345678 & 0000fffff
lo = 0x00005678
 
faire un | de ces deux parties va donner le nombre d'origine.
 
hi = hi >> 16
hi = 0x00001234
 
lo = lo << 16
lo = 0x56780000
 
reverse = hi | lo = 0x56781234

c'est l'inverse. tu n'as jamais fait de binaire ?

 
Génial, j'ai compris. Merci...

 
...si peu !

je te conseille un week-end romantique avec les opérations logiques ...

 
Ce week end, c'est avce ma copine normalement, j'crois qu'elle le prendrais mal si j'décommandais pour les opérations logiques (jalousie oblige )
Merci à tous  

heu... un long c pas codé sur 4 octets ?!?

 
c'est code sur (CHAR_BIT * sizeof long) bits exactement

 
Ben, dans ce cas là en tout cas, c'est ce qu'on considère...
32 bits quoi !

bin alors : l'auteur du sujet (el_gringo) dit :
 
inverser la partie haute et la partie passe d'un long.
Donc : passer les 4 premier octets en dernier et les 4 derniers en 1er. De sorte que 0xAB802453 devienne 0x2453AB80 (c pour un codage).
 
il a confondu octets avec chiffre hexa alors ?
 
enfin ... p-e si j'avais lu le topique en entier ca irait mieux ...
 
et si on fait :
 
long LongAInverser;
 
char tmp[2];
 
memcpy((void*)tmp,((void*)((&LongAInverser)+2),2);
memcpy(((void*)((&LongAInverser)+2),((void*)(&LongAInverser),2);
memcpy(((void*)(&LongAInverser),((void*)tmp,2);
 
(enfin c la théorie, g pas chercher à compiler ni rien, en fait ca serait de copier directement les 2 1ers octets à la place des 2 derniers et inversement)

Et comme ça, c'est pas plus propre ?
 

 
Ben, El_Gringo il pense que dans 0x11223344, 11 est un octet, 22 un autre, 33 encore un, et 44 le dernier...

Ça serait trivial si on disposait de l'opérateur de rotation:

Comme d'habitude ,il y a sûrement des librairies qui font ça très bien.

"si on disposait" mais alors ca existe ton code ?

non

<<< existe en Java il me semble.
Et il me semble aussi qu'il a d'abord demandé dans la rubrique Java, donc ça peut lui servir.
 
Pour disposer de la rotation, il faudrait une librairie capable d'utiliser les instructions assembleur si elles existent.

oui, il existe mais ce n'est pas la rotation, il me semble. je crois que c'est un histoire de décalage avec un injection de 1

qq1 pourrait-il me donner un lien ou m'expliquer les << >> je c kil le faut ds cout par exemple mais je n'ai jms compris sa signification.

mais la c'est la surcharge d'opérateur. le << des ostream n'a rien à voir avec le << qu'on utilise sur des int

ah ... bin qq1 pourrait-il m'expliquer les 2 ou me donner un lien svp ?

ben pour les ostream c'est une surcharge, ca signifie juste "ecrire la representation de truc dans le flux"
 
pour les int, c'est un décalage binaire vers la gauche
 
i=1
 
j=i << 2
 
j==4

ok, d'accord, merci ))
 
je suppose que >> décale les bits vers la droite ?

et au fait pour j = i << 2
le bit tout à gauche passe à droite ou il est viré e tle bit rajouté à droite est tjs un 0 ?

avec << les bits de droite sont perdus et des 0 sont injectés par la gauche. c'est valable pour les type signés et non signés (signed et unsigned)
 
pour >>, sur les types non-signés, des 0 sont injectés par la droite. les bits de gauche sont perdus.
par contre sur les types signés (int par exemple), les bits injectes a droite peuvent etre 1 ou 0 selon la machine: ce n'est pas défini par la norme, donc attention

ok, mci bcp

 
Il me semblait que sur les types signés, >> devait conservé le signe et donc que >> recopie le bit de poit fort pour cela.

non (je paraphrase le K&R chapitre 2.9)
 
selon la plateforme, il s'agit donc soit d'un décalage logique soit arithmétique.

Grand boutiste, va !
 
Il faut permuter gauche et droite. Les poids faibles sont conceptuellement placés à droite, quel que soit le boutisme du système.

ben ouais  

 
oui, parce que reellement, il faudrait savoir comment sont placées les barrettes memoires dans la machine

ah ... bien ... c koi le boutisme ?