Manipulation de fichiers : perte de données

Gl : woohoo en reprenant mon code initial(c'est à dire celui que j'ai posté avec mes strings et mes char* dégueux) et en modifiant juste ce qui tu as dis ça fonctionne nikel.

Je comprenais pas non plus pourquoi en C ça marchait et pas quand je mélangeais ça avec du C++. Le but n'étant pas de faire un patchwork, mais comme je navigue à vue avec le C++, je colmate les fruits de mon ignorance avec du C.

Bon sinon le void main(void) je suis au courant, mais est-ce que fondamentalement ça va changer le cours du Yen ?

3DArchi : c'est vrai que là je n'ai rien identifié, étant donné que j'ai même pas un bout de code qui compile =) Mais je me pose la question en avance de phase, question de pas me retrouver avec un truc qui rame pour des gros volumes et de devoir tout réécrire autrement parce qu'avec cette méthode là on ne sait pas faire autrement.(dans le cas bien sur ou avec cette méthode là on ne saurait pas faire autrement =) ).

La science progresse (moi non mais c'est pas grave =) ).

Citation:

---

Envoyé par Vojenbon

Bon sinon le void main(void) je suis au courant, mais est-ce que fondamentalement ça va changer le cours du Yen ?

---

Qui sait ?

Citation:

---

Envoyé par Vojenbon

(dans le cas bien sur ou avec cette méthode là on ne saurait pas faire autrement =) ).

---

Facilement modifier pour optimiser, tu pourras.

Citation:

---

Envoyé par Vojenbon

La science progresse (moi non mais c'est pas grave =) ).

---

A moins que ce ne soit l'inverse ...

Alors par ailleurs, dans le but de faire évoluer les mentalités dans les populations qui pratiquent des rîtes vaudou au Sud du Groenland, j'ai déclaré une série de char et d'unsigned char, j'ai fait des XOR avec les uns et les autres pour voir ce que ça donnait.

Genre si je mets 206 dans un char, à l'affichage ça me met -50. Si je mets -50 dans un unsigned char, à l'affichage ça me met 206. J'ai aussi fait des XOR, en d'abord sans mélanger, puis en mélangeant signés et non signés, les résultats finaux sont toujours identiques.

C'est à dire que l'on fasse 206 ^ 'A' ou -50 ^ 'A', ça fait toujours pareil. Le codage binaire ne change pas(j'ai testé avec des bitset notamment, et -50 = 206).

La où ça devient plus délicat, c'est si on se mettait à additionner tout ça avec un entier par exemple. Là c'est plus du tout pareil. Mais tant qu'on reste dans le char ça marche. Enfin ça marche... pour le XOR, pour la multiplication c'est moins sur hein, en même temps le gars qui s'amuse à multiplier 'A' par -50, hein bon... ok ça pourrait être moi.

Sinon je pense qu'il faut délester d'urgence ce post avant qu'une âme pure et innocente ne vienne à tomber sur les immondices que je raconte.

Vers l'infini et au-delà.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#include <iostream>   template<typename byte_> void dump(byte_ b_) { unsigned int val = b_&0xff; std::cout<<std::hex<<val<<"\n"; } int main() { char c=-128; unsigned char uc=-128; dump(c); dump(uc); c = c>>1; uc = uc>>1; dump(c); dump(uc);   return 0; }

---

Sortie :

Citation:

---

80
80
c0
40

---

La façon dont est traitée le bit de signe dans certaines opérations de ce type (décalage) est dépendante du compilateur et non de la norme il me semble. D'où la préconisation d'utiliser toujours des versions non signées lorsqu'on manipule les bits de l'octet. Note que pour être vraiment sur tu pourrais carrément t'appuyer sur un std::bitset.

L'avantage dans mon cas c'est que le résultat en soit m'est égal.
Il faut simplement que si A^B donne C alors C^B donne A. Au moins ça c'est bon.

Je me suis permis de modifier

Code:

---

1 2	unsigned int val = b_&0xff; std::cout<<std::hex<<val<<"\n";

---

Code:

---

1 2 3

unsigned int val = b_&0xff; std::bitset<8> valb = val; std::cout<<std::hex<<val<<"\t"<<valb<<"\n";

---

Avec le binaire on voit bien que le bit de parité est conservé lors d'un décalage. Espérons que notre langue reste une langue vivante.