voila un copain ma demande ce que c etai que les objet c++ suivant :
 
little endian
big endian
 
mais j ai pas su lui dir alors je vien vous demande
 
mci

Ce ne sont pas des objets, mais un type de codage.
Ca dépend de la façon dont le processeur gère les entiers.
 
Prenons l'exemple d'une entier de 4 octets 0x44332211 en héxa.
Un processeur x86 va stocker en mémoire les octets 0x11 puis 0x22, 0x33 et enfin 0x44.
D'autres processeurs feront l'inverse en stockant d'abord l'octet de poids fort 0x44.
 
Ca pose problème quand tu envoies des données d'un ordinateur à l'autre. Les 4 octets représentant l'entier ne seront pas compris de la même façon.
 
Mais je sais jamais lequel est lequel
 
edit : évidemment, j'ai inversé le sens

intel il le stocke "à l'envers" il me semble, donc si tu regardes en hexa un fichier où tu as écris un integer, tu auras l'octet de poids faible en premier
donc 1 s'écrira 01 00 00 00 (4 octets, 4x 2 digits hexa), ça c'est big endian je crois...

C'est l'idée mais en fait c'est l'inverse. Les x86 sont little-endian, et vont stocker 0x44 (le "little end" ) en premier (aux adresses basses), et le 0x11 (le "big end" ) en dernier (aux adresses hautes).
 
Les processeurs Motorola, eux, sont par contre big-endian.
 
 
Edit : je réponsais bien sûr à mrbebert, antp s'est intercallé.
 
Re-edit après le 4ème post d'antp : évidemment ce qui est au dessus est faut. Le "little end" c'est 0x11, et c'est finalement tout comme a dit mrbebert.

oui, exact, je me suis planté dans l'écriture du nombre en hexa  

heu t'es sûr que l'intel inverse pas ?
pcq quand je dois comparer une valeur lue dans un fichier, genre 0x11223344 vu par un éditeur hexa, en Pascal je dois taper $44332211

 
j'ai dans mon fichier vu en hexa : 02 00 00 00

Oui c'est ce que j'ai dit : l'octet le moins significatif en premier. Je répondais à mrbebert, tu t'es intercallé entre temps

Moi j'aime pas les indiens
 
 

Matafan a écrit a écrit : Oui c'est ce que j'ai dit : l'octet le moins significatif en premier. Je répondais à mrbebert, tu t'es intercallé entre temps

 
dans ton post j'ai l'impression que tu disais le contraire

Ah oui effectivement le petit bout c'est 0x11, pas 0x44 Donc mrbebert avait raison. En fait le truc c'est que j'imaginais l'exemple 0x11223344... Mais bon pas d'excuses.

Matafan a écrit a écrit : Ah oui effectivement le petit bout c'est 0x11, pas 0x44 Donc mrbebert avait raison. En fait le truc c'est que j'imaginais l'exemple 0x11223344... Mais bon pas d'excuses.

Je lui dit ou pas que c'est ce que j'avais mis quand il a écrit son post et que j'ai inversé ensuite

Rah le sauvage
Va finir par être dur à suivre ce thread

Bref, on parle d'inversion de posts... pardon, d'octets.
 
Si on stocke des nombres de 4 ou 2 octets à l'adresse 0:

Le little-endian a l'avantage que les octets de même poids se trouvent au même endroit quelque soit la taille du type écrit.
 
Les éditeurs hexadécimaux nous embrouillent, car ils écrivent les octets comme du texte (de gauche à doite), alors que les deux chiffres héxadécimaux composant un octet sont écrit comme des chiffres (de droite à gauche):

Le big-endian a l'avantage d'être plus lisible sous cette forme, mais c'est bien le seul intérêt que je que lui trouve.
 
 
Donc, les processeurs intels n'inversent rien du tout, pas plus que les motorola.
Ils sont l'inverse l'un de l'autre, c'est tout.

merci pour vos reponse et correction ^^