Discussion :

[damien7307]

Bonjour,

Ceci est mon premier post sur ce forum. J'ai une année de pratique du C++.

---

Voici ma question :

Ce petit bout de code me donne un resultat que je trouve étrange :
Il s'agit d'ouvrir un fichier bmp et d'en lire les 5 premiers caractères

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
ifstream fichier("test.bmp", ios::in | ios::binary);	
 
	for(short int i = 0; i<5; ++i)
	{
		char c;
		fichier.get(c);
 
		cout<<(int) c<<endl;
	}
 
fichier.close();

Sortie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
66
77
-8
-41
13

On remarque que les deux premiers caractères (66 et 77) correspondent respectivement au 'B' et 'M' de l'en-tête du fichier BMP.

Seulement, pourquoi est-ce que les deux caractères suivants sont négatifs ?

De plus, si on exécute cet autre bout de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
ifstream f("test.bmp", ios::in | ios::binary);	
 
	int i = 0;
	char c[2];
 
	f.read( &c[0], sizeof(char) );
	f.read( &c[1], sizeof(char) );
 
	f.read( (char *) &i, sizeof(int) );
 
	cout<< c <<endl;
	cout<< i <<endl;
 
f.close();

on obtient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
BM°Î
907256

Où 907 256 correspond à la taille du fichier bmp en octet (cf. résumé sur le format bmp : http://andrew.csie.ncyu.edu.tw/zip/Bmp1.htm)

Ne devrais-je pas avoir en sortie:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
BM
907 256

?

Je vous remercie d'avance pour vos réponses

Damien

---

Note : voici le début de l'en-tête d'un fichier bmp

+--------+--------+--------+--------+
| Char 'B' | Char 'M'| Taille en [...] |
+--------+--------+--------+--------+
| octets du fichier |
+--------+--------+--------+--------+

[nouknouk]

salut et bienvenue !

en C/C++ un char représente une valeur signée stockée sur 8 bits (un octet).

Je pense que dans ton cas tu voudrais plutôt utiliser des unsigned char.

[Mac LAK]

Les char sont par défaut signés sur la plupart des plate-formes, donc toute valeur supérieure à 127 devient "négative". Comme tu castes ça en int (signé lui aussi), le signe est conservé. Ce sont des bases d'arithmétique binaire.

Lis des unsigned char et/ou affiche des unsigned int, tu ne devrais plus avoir le problème.

[Arzar]

Bonjour,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
char c[2];
c[0] = ...
c[1] = ...
//...
cout<< c <<endl;

on obtient :

BM°Î
907256

Il manque un '\0' à la fin du tableau de char. Donc std::cout va continuer à afficher la mémoire case par case en sortant du tableau juqu'à ce qu'il en trouve un.

[3DArchi]

Bonjour,

Ceci est mon premier post sur ce forum. J'ai une année de pratique du C++.

Bonjour et bienvenu,

Seulement, pourquoi est-ce que les deux caractères suivants sont négatifs ?

Partons du fichier : celui-ci est une suite d'octets, qui si on les note hexadécimal, donne le flux suivant :

0x42 0x4D 0xF8 0xD7 0x0D 0x00

char est de type signé. Les deux premiers items sont positifs mais les deux suivants sont négatifs et utilisent le complément à 2 pour leur représentation. Si tu fais l'exercice de les convertir depuis leur représentation binaire vers la représentation décimal (en utilisant cette représentation des nombres négatifs avec le complément à 2), alors tu verras qu'ils représentent bien le -8 et le -41 qui te sont affichés.
Quand on veut travailler avec des 'octets', on utilise en général unsigned char. Ce type n'est pas signé donc les 'octets' correspondent à ce que tu attends. Ainsi, tu peux changer ton code et regarder ce qu'il se passe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
ifstream fichier("test.bmp", ios::in | ios::binary);	
 
	for(short int i = 0; i<5; ++i)
	{
		unsigned char uc;
		fichier.get(uc);
 
		cout<<(int) uc<<endl;
	}
 
fichier.close();

[HS]Notes que je mets 'octets' entre guillemet car la norme ne te garantie pas qu'un char/unsigned char est sur un octet même si en pratique sur PC c'est toujours le cas. Considérons donc avec un peu d'abus de langage que unsigned char == octet [/HS]

Ne devrais-je pas avoir en sortie:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
BM
907 256

?

1/Un tableau de char est traité - vieux reste du C - comme une chaîne de caractère et s'attend donc à un '\0' pour délimiter la fin de la chaîne. Or ton tableau de char ne contient que 2 éléments 'B' et 'M' ensuite il va chercher les valeurs à la suite qui contiennent des valeurs indéterminées et affichent donc n'importe quoi.
2/Attention, tout comme précédemment la représentation binaire d'un char a une influence entre ce que tu crois lire et ce qui sera interprété par ton programme, tu ne peux lire un entier par la simple commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

f.read( (char *) &i, sizeof(int) );

En effet, ici, le problème n'est plus au niveau de l'octet char/unsigned char mais de l'endianess. En d'autres termes, le nombre 907256 qui s'écrit en hexadécimal 0x000DD7F8 peut se retrouver selon la suite d'octets :
0x00 0x0D 0xD7 0xF8
ou
0xF8 0xD7 0x0D 0x00
Avec la lecture 'sauvage' f.read( (char *) &i, sizeof(int) );, i peut valoir 907256 (0x000DD7F8) ou 4174843136 (0xF8D70D00) car rien ne garantie que l'endianess utilisé pour écrire le fichier est le même que celui utilisé dans ton programme. Il faut pour cela vérifier l'endianess utilisé dans la norme BMP et opérer la conversion adéquate dans ton programme pour correspondre avec celle utilisée par les int de ton programme.
Le problème d'endianess se pose pour tous les types entiers : short, int, long.

[damien7307]

Merci "3DArchi" pour votre réponse claire et complète. Mon problème est résolu. Il me reste encore du travail avant de bien maitriser ce language.

En effet l'erreur du '\0' est trop bête, j'aurais dû y penser...

Merci également aux autres pour leur réponse

Damien.

[JolyLoic]

char est de type signé.

Petit détail : char peut être signé ou non signé, c'est au choix de la plate-forme. Unisgned char est non signé, signed char est signé.

[3DArchi]

Petit détail : char peut être signé ou non signé, c'est au choix de la plate-forme. Unisgned char est non signé, signed char est signé.

Me coucherais moins bête ce soir.

[Mac LAK]

Petit détail : char peut être signé ou non signé, c'est au choix de la plate-forme. Unisgned char est non signé, signed char est signé.

Oui, c'est dépendant de la plate-forme (ou du réglage par défaut du compilateur, c'est notamment le cas avec Visual). Cependant, c'est souvent signé par défaut, et dans le doute, il vaut mieux systématiquement préciser "signed" ou "unsigned" si la notion de signe est importante dans le traitement.