Bonjour,
j'ai vu que certaines architectures comme SPARC ne tolèrent pas les accès non-alignés, donc je souhaite les éviter complètement, voulant produire du code portable. Toujours voulant produire du code portable, je souhaite travailler avec des octet et non des byte (même si c'est la même chose dans la majorité des cas).
Or:
Ce code ne peut il pas poser doublement problème ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 uint32_t buffer[ 16 ]; std::ifstream file("mon_fichier.bin"); file.read(reinterpret_cast <char*> (buffer), 64);
1. Si j'ai compris le principe de l'alignement, on va ici écrire des bytes au milieu d'un uint32_t.
2. on extrait des bytes (la méthode read est faite ainsi) !!! donc j'hypothèse que si un byte fait 9bits sur mon système, en remplissant le buffer je vais écrire 64 fois 9 bits = 576 bits alors que j'aurais voulu écrire 64 * 8 bits = 512 bits: dépassement. catastrophe. sans compter que ça sera pas aligné comme je le souhaite. Je suis confus parce que wikipedia indique que même si uint32_t par exemple fait 32 bits, il est aussi garanti qu'il fasse 4 bytes... si le byte est plus gros, y a-t-il bourrage ? mais dans ce cas, j'aurais pas des soucis en voulant bricoler à l'intérieur, en faisant un décalage par exemple ?
EDIT:
Si problème il y a effectivement, une solution pourrait être d'utiliser carrément un std::basic_istream <uint32_t> au lieu de std::istream (qui utilise des char).
Seulement cela suppose pour moi de convertir un ifstream par exemple (càd un istream) en basic_istream <uint32_t>. je vais tester mais je ne sais pas encore ce que ça implique...
mais y a-t-il effectivement un problème ?
EDIT2: uint32_t est remplacé par unsigned int ....
Partager