Bienvenue, Invité. Merci de vous connecter ou de vous inscrire.
Avez-vous perdu votre e-mail d'activation ?

Auteur Sujet: Résolution du problème d'endianness  (Lu 2423 fois)

0 Membres et 1 Invité sur ce sujet

janf

  • Newbie
  • *
  • Messages: 45
    • Voir le profil
Résolution du problème d'endianness
« le: Février 03, 2017, 12:59:16 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Re : Résolution du problème d'endianness
« Réponse #1 le: Février 03, 2017, 01:15:16 pm »
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.
Laurent Gomila - SFML developer

janf

  • Newbie
  • *
  • Messages: 45
    • Voir le profil
Re : Résolution du problème d'endianness
« Réponse #2 le: Février 03, 2017, 01:19:00 pm »
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 ?
« Modifié: Février 03, 2017, 01:20:45 pm par Renardesque »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Re : Résolution du problème d'endianness
« Réponse #3 le: Février 03, 2017, 04:15:39 pm »
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).
Laurent Gomila - SFML developer

janf

  • Newbie
  • *
  • Messages: 45
    • Voir le profil
Re : Résolution du problème d'endianness
« Réponse #4 le: Février 03, 2017, 05:01:09 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Re : Résolution du problème d'endianness
« Réponse #5 le: Février 03, 2017, 05:34:45 pm »
Citer
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 ;D
Laurent Gomila - SFML developer

 

anything