Résolution du problème d'endianness

[janf]

Bonjour !

Je viens poser une question d'ordre totalement général pour combler mes lacunes. J'aurais pu le faire sur un autre forum éventuellement, mais comme j'ai été introduis à ce problème par le tuto sfml sur les socket et les sf::Packet et que j'utilise la SFML, je me permets de poster ici.

Dans le tuto sur l'envoie de sf::Packet il est dit que pour éviter les problèmes de différence d'endianness entre les machines, plutôt que d'utiliser les types numériques pré-inclus dans le C++ (int, long...) il valait mieux utiliser les types de la SFML tels que sf::Int8, sf::Uint16 etc. Mais il est dit dans la documentation que c'est types ne sont ni plus ni moins que des alias pour les types du C++. Comme le sont les types uint8_t etc. du header cstdint.h.

Du coup je me demandais par quel procédé le fait d'utiliser des alias réglait le problème d'endianness lors de la communication sur le réseau ?

J'espère vraiment que ma question a sa place ici et qu'elle trouvera quelque passionné de l'informatique bas niveau pour me répondre.

[Laurent]

Les types à taille fixe évitent les problèmes de différence de taille, pas les problèmes de boutisme (endianness). Ces derniers sont résolus par une sérialisation des types octet par octet (plutôt qu'envoyer directement la réprésentation mémoire de la variable).

Pour ce qui est des types à taille fixe c'est très simple, il suffit de tester des symboles pré-processeur bien choisis qui permettent d'orienter le typedef vers l'un ou l'autre type natif qui va bien.

#ifndef MSVC
    typedef Uint64 unsigned long long;
#else
    typedef Uint64 __uint64;
#endif

(exemple fictif mais proche de la réalité)

Ceci-dit, en pratique, on peut bien souvent largement simplifier ces règles, comme SFML le fait.

[janf]

Ok merci !

Mais alors, pour être allé farfouillé dans le code de la fonction receive des socket TCP pour les sf::Packets, elle effectue un memcpy d'un seul coup si je me souviens bien. Cela permet-il cette résolution de différence d'endianness ? Il n'y aurait pas besoin d'inverser les octets sur une machine à l'endianness inverse ?

[Laurent]

C'est sf::Packet qui effectue cette tâche, sf::TcpSocket ne fait que recevoir des données brutes non interprétées (c'est la couche de transport).

[janf]

Ok merci, j'irai voir de plus près dans le code de sf::Packet. Merci pour la SFML, personnellement ça a été mon point d'entrée dans de nombreux domaines de la programmation. Et c'est du beau code. J'ai pas encore vu les sources de la dernière version, mais si j'ai bien compris c'est du C++11 maintenant. C'est classe

[Laurent]

J'ai pas encore vu les sources de la dernière version, mais si j'ai bien compris c'est du C++11 maintenant

Non pas encore. C'est un peu la honte