Discussion :

[BioKore]

Bonjour à tous,

Ces quelques derniers jours, j'ai dépoussiéré un projet réalisé il y a 2 ou 3 ans sous linux (dont on retrouvera des vestiges dans différents posts sur ce forum), nécessitant la lecture de fichiers de type *.idx.
Sans grande surprises, à la lecture du code réalisé à l'époque, ce dernier nécessite une totale refactorisation compte tenu de ma prise de maturité dans le langage depuis (merci au forum !!!).

Je m'y plonge donc, et, cette fois-ci par contre, grande surprise ! La sortie fournie par l'outil ne correspond pas à celle attendue (censée être finalement la même que le code initial).

Je retourne donc le code dans tous les sens, essaie d'autres méthodes, m'assure plutôt 10 fois qu'une que l'algorithme est viable etc... Bref, le code qui devais être une mise au propre devient alors un code de test... Rien y fait. En 3 jours de recherche, même le code initial qui me servait de base recrache toujours la même chose : une sortie tronquée (pas fausse, tronquée ; une partie des infos semble corrompue) par rapport à ce qui est attendu.
Je me dit, "ok, j'utilise GCC en powershell, peut-être que le sujet vient du compilo". J'installe donc Code::Blocks (ayant formaté il y a peu, avec windows on en prends l'habitude) et là, le résultat est exactement le même (normal ; MINGW = GCC).
Ayant eu des soucis lors de l'installation de code-blocks (pas sure du compilateur utilisé) et n'arrivant pas à le désinstaller complètement, je formate donc (encore... Pauvre SSD....) et test à nouveau avec code-blocks sur une installation brute (+ mises à jour windows et Drivers). Résultat. Toujours le bug.

Je réfléchis donc encore un peu : "le code de base fonctionnait à l'époque, moche, lent, absolument pas optimisé, mais les sorties étaient correctes et faisaient le taff. Je vais tester mon nouveau code (finalement à refaire quand même suite aux modifications vues précédemment mais bon) sur mon ancienne machine". Et là, illumination. Tout fonctionne nickel.

Verdict surprenant : le bug que j'ai, ne faisant appel qu'à des fonctions de base de la STL, est erratique sous Windows et fonctionne très bien sous Débian !! Pourquoi ???

Pour info, le code ne fait que charger 60'000 "images" de 28 pix * 28 pix au format IDX dans un vecteur lui même encapsulé dans une structure, et m'affiche à la demande l'image n° X ou Y. Je ne fais donc qu'intervenir des for, std::vector et std::fstream.

Le code complet étant suffisamment long pour n'avoir que peu d'intérêt ici, je ne mettrais que les parties "intéressantes". Bien entendu, si vous souhaitez en voir l'intégralité, il suffit de demander (finalement, on en est pas loin):

La déclaration de la classe principale (et des structures sous-jacentes) :

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#pragma once
 
#include <cstdlib>
#include <string>
#include <vector>
#include <iostream>
#include <fstream>
 
 
struct LabelSet {
	size_t magic;
	size_t size;
	std::vector<unsigned char> labels;
};
 
struct PictureSet {
	size_t magic;
	size_t size;
	size_t rowDim;
	size_t colDim;
	//std::vector<std::vector<std::vector<unsigned char> > > pictures;
	std::vector<std::vector<unsigned char> > pictures;
};
 
enum TYPE_SET { IDX_LABEL, IDX_PICTURE };
 
class IDX_Reader {
private:
	LabelSet mLabel;
	PictureSet mPicture;
 
public:
	IDX_Reader();
 
	void load(TYPE_SET const & SET, std::string const & path);
	void loadLabel(std::fstream & labelFile);
	void loadPicture(std::fstream & pictureFile);
 
	void read(size_t const id);
 
};
 
 
// EOF

Rien de bien méchant jusque là...
Les déclarations des deux principales fonctions utilisées (en tout cas celles que j'estime pouvant être à l'origine du bug) :

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
void IDX_Reader::loadPicture(std::fstream & pictureFile) {
	mPicture.magic = (pictureFile.get() << 24) | (pictureFile.get() << 16) | (pictureFile.get() << 8) | pictureFile.get();
	mPicture.size = (pictureFile.get() << 24) | (pictureFile.get() << 16) | (pictureFile.get() << 8) | pictureFile.get();
	mPicture.rowDim = (pictureFile.get() << 24) | (pictureFile.get() << 16) | (pictureFile.get() << 8) | pictureFile.get();
	mPicture.colDim = (pictureFile.get() << 24) | (pictureFile.get() << 16) | (pictureFile.get() << 8) | pictureFile.get();
 
	//case of 2D vector
	mPicture.pictures.clear();
	mPicture.pictures.resize(mPicture.size);
	for(auto & pic:mPicture.pictures) {
		pic.resize(mPicture.rowDim * mPicture.colDim, 0);
		for(auto & pix:pic) {
			pix = static_cast<unsigned char>(pictureFile.get());
		}
	}
 
	// case of 3D vector
	/*mPicture.pictures.clear();
	mPicture.pictures.resize(mPicture.size);
	for(auto & pic:mPicture.pictures) {
		pic.resize(mPicture.rowDim);
		for(auto & row:pic) {
			row.resize(mPicture.colDim, 0);
			for(auto & col:row) {
				col = static_cast<unsigned char>(pictureFile.get());
			}
		}
	}*/
 
}
 
 
void IDX_Reader::read(size_t const id) {
	std::cout << "Printing picture of index " << id << '\n';
	std::cout << "Label : " << static_cast<unsigned short>(mLabel.labels[id]) << '\n';
 
	// case of 2D vector
	for(size_t r{0}; r != mPicture.rowDim; ++r) {
		for(size_t c{0}; c != mPicture.colDim; ++c) {
			if(mPicture.pictures[id][c + (r * mPicture.colDim)] > 0) {
				std::cout << 'x';
			} else {
				std::cout << ' ';
			}
		}
		std::cout << '\n';
	}
 
	// case of 3D vector
	/*for(auto & row:mPicture.pictures[id]) {
		for(auto & col:row) {
			if(col > 0) {
				std::cout << 'x';
			} else {
				std::cout << ' ';
			}
		}
		std::cout << '\n';
	}*/
 
 
}

Et, je mettrais bien une extraction des sorties attendues (fournies par la fonction IDX_Reader::read(size_t const id)) mais je dois encore ré-installer virtual-box et / ou trouver une manière de reproduire une version buguée et une non buguée sur la même machine...

Mais globalement, les images (en niveau de gris [0 - 255]) doivent apparaitre à l'écran en mode console (voir algo de la fonction IDX_Reader::read(size_t const id)). Mais sous windows, à partir de la moitié de l'image 5, l'affichage apparait comme si les pictureFile.get() n'étaient pas faits (toutes les valeurs sont à 0, 255 si non défini dans le resize).


Dernière précision, sur mes deux machines, unsigned char = 8bits // int = 32 bits, les processeurs sont intel (des core I-7 86-64 sur les deux même si pas de même génération). Rappel : Intel = Litle Endian




Une idée de comment compiler ça sous windows ? A mon avis, au prochain format, je repasse sous Buster + XFCE4....


Merci d'avance !

[jo_link_noir]

L'une des premières choses que je fais est de sortir les analyseurs dynamiques: asan et compagnie pour le compilateur (-fsanitize=address,undefined) et valgrind.

En plus d'activer le debug de libstdc++ (-D_GLIBCXX_DEBUG (ou -D_GLIBCXX_ASSERTIONS pour avoir la compatibilité de l'abi)) et libc++ (-D_LIBCPP_DEBUG=1 qui possède un bug avec les versions fournit avant clang-8).

La majorité du temps, il n'y a pas à chercher plus loin. Le problème apparaît, il ne reste qu'à comprendre son cheminement.

[BioKore]

Que des choses que je n'ai jamais fait !

Je vais essayer de comprendre comment donner toutes ces commandes à manger à Code::Blocks (je n'ai pas re-install GCC pour powershell, mais ce n'est finalement peut être rien d'autre que MingW finalement ?).
Je test tout ça et je fais mon retour.

Merci pour les tips !

[koala01]

Salut,

Déjà, juste un truc :

Si, pour la facilité, tu créais une fonction de IDX_reader capable d'extraire des entiers de type int, sous une forme proche de

Code :

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

1
2
3
4
5
6
7
8
int extractInteger(std::fstream & ifs){
    int temp;
    temp| ifs.get()<<24;
    temp | ifs.get()<<16;
    temp | ifs.get() <<8;
    temp | ifs.get() <<0;
    return temp;
}

Cela te permettrait déjà de simplifier le code de fonction loadPicture sous une forme proche de

Code :

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

1
2
3
4
5
void IDX_Reader::loadPicture(std::fstream & pictureFile) {
    mPicture.magic =extractInteger(pictureFile);
    mPicture.size = extractInteger(pictureFile);
    mPicture.rowDim = extractInteger(pictureFile);
    mPicture.colDim = extractInteger(pictureFile);

De même, au lieu d'utiliser un tableau de tableau de char, tu pourrais sans doute envisager de "linéariser" cette matrice, le nombre de pixels que tu t'attends à extraire étant forcément égal à rowDim * colDim, l'indice de chaque pixel pouvant être calculé grâce à la formule générique index_recherche = row * colDim + col (les formules pour récupérer respectivement les lignes et les colonnes, si nécessaires, correspondant à row = index / colDim et col = index % colDim)

De manière générale, un std::vector occasionnant systématiquement 24 bytes (ce n'est peut-être que 12 en 32bits )d'utilisation mémoire de plus pour maintenir les différentes informations dont il a besoin, à savoir: un pointeur sur le début de l'espace mémoire + un espace pour contenir sa taille + un espace pour contenir sa capacité, travailler sur un tableau de tableau pour représenter une image de 27 lignes * 27 colonnes double pour ainsi dire (ou peu s'en faut) la mémoire utilisée pour la représentation de ton image, ce qui justifie amplement de faire la conversion, non

Cela ne changera rien au comportement, mais, au moins, tu éviteras les copier / coller, et s'il s'avère que tu dois modifier ce comportement, tu auras la certitude de le faire partout où il est utilisé, sans risque d'oublier de modifier le comportement de rowDim, par exemple (le fameux DRY de l'Xtrem Programming, ca te dit quelque chose )

sous windows, à partir de la moitié de l'image 5, l'affichage apparait comme si les pictureFile.get() n'étaient pas faits (toutes les valeurs sont à 0, 255 si non défini dans le resize).

Il me semble avoir été confronté (en tant qu'utilisateur) à un comportement similaire d'une application à l'époque

[BioKore]

Tout à fait d'accord concernant le extractInteger(pictureFile) c'est même entièrement au programme (j'ai bien connaissance du principe DRY )

Par contre, si j'ai bien compris (à confirmer !), en ce qui concerne la linéarisation du vecteur, ce n'est pas vraiment prévu dans le sens où ce qu'il m'importe n'est pas d'avoir un seul vecteur unique contenant toutes les images, mais bien de pouvoir récupérer un vecteur (voire un double vecteur selon les applications que j'envisage) pour chaque image récupérée. Attention, je rappelle, chaque image est ici déjà linéarisée ; si j'utilise un tableau de tableau c'est parce que j'ai 60'000 images de 28 * 28 ; j'ai donc un vecteur de 60'000 * un vecteur de 784. Je dois pouvoir en suite manipuler les images une par une et c'est bien plus pratique / ouvert de les utiliser au format std::vector que selon une structure particulière. Après, la vraie question, c'est est-ce que c'est à mon "lecteur" IDX de faire la conversion en vecteur plutôt qu'à une classe intermédiaire entre le lecteur et l'application finale ? Là, ça se discute !
Aussi, réaliser une structure permettant de tout stocker dans un seul vecteur de 47'040'000 char (plutôt que 60'000 vecteurs de 784 char) permet une économie de 1.4Mo de ram dans le cas présent soit moins de 3% de la mémoire totale utilisée par la structure.... Cela en vaut-il vraiment le coup ? Ce gain ne risque t-il pas d'être perdu dans une classe de transformation voire même d'être traduit en une perte de performance pour l'exploitation des données ?

Pour être honnête, je n'ai pas encore trop réfléchis à l'optimisation du stockage. J'ai bien conscience de l'importance de le faire dans le cas présent, mais pour le moment, ma priorité est de faire fonctionner le programme (même dans sa version la plus sommaire) sous windows. Je veillerais à faire une structure (classe ?) plus optimisée pour le stockage par la suite.

Mais merci quand même pour ces précieux conseils !

D'ailleurs, peut-on m'expliquer comment s'utilisent les outils préconisés par jo_link_noir ? Car le debuger me dit que tout va bien (avec les options données) mais j'ai tenté de donné -fsanitize=address,undefined à manger à mon compilateur et visiblement, il est pas content du tout (mingw32-g++.exe -Wall -g -pedantic -Wextra -Wall -std=c++14 -pg -Og -g -fsanitize=address -fsanitize=undefined -D_GLIBCXX_ASSERTIONS -D_LIBCPP_DEBUG=1 -D_GLIBCXX_DEBUG pour les options).
Insulte du compilateur : "internal compiler error: in pp_format, at pretty-print.c:611" Le tout dans le fichier "formatter.h", ligne 390.

Première fois que je me lance dans une opération de débogage ; soyez indulgent svp

[Bousk]

Si tes images sont de taille fixe tu peux très bien avoir 1 vector de 60000*28*28. Et accéder à une image ou l'autre est un simple index * 28 * 28

[jo_link_noir]

Quelle version de gcc correspond à mingw ? Il y a eu pas mal de changement dans la structure interne gcc et un moment (1 an ?), le compilateur n'était plus capable d'afficher certaines erreurs (et je suppose avertissement) sans planter.

En tout cas tu peux activer les paramètres un à un pour savoir lequel bug. Bien possible que les sanitizers ne fonctionnent pas convenablement sur Windows. Au niveau des defines, c'est soit GLIBCXX_ASSERTIONS soit GLIBCXX_DEBUG, DEBUG étant plus agressif, mais n'est pas activé si ASSERTIONS est présent. LIBCPP_DEBUG quant à lui concerne la lib standard de clang, ce n'est pas utile avec mingw/gcc. D'autant plus que libc++ ne fonctionne pas avec gcc.

Par contre, je ne sais pas pourquoi tu mets -pg, c'est une option pour le profiler (gprof).

Pour un équivalent de valgrind sur Windows, il y a Dr. Memory. Sinon tu peux aussi compiler avec WSL qui permet d'avoir un environnement Linux sur Windows.

[BioKore]

merci pour ces retours.

@Bousk : je comprends bien l'idée derrière tout ça et je me sent tout à fait prêt à manipuler un tel vecteur. Le truc c'est que je souhaite passer mes images à différentes fonctions, qui elles, doivent être en mesure de traiter toute taille d'image et RAPIDEMENT. Je ne peut pas me permettre de rajouter une couche venant interpréter le vecteur en plus. Aussi, ici, elles ne font que 28 * 28, mais si demain elles font 16 * 128 (a titre d'exemple uniquement), je compte bien utiliser ces mêmes fonctions sans avoir à devoir leur donner la taille de l'image ou autre. Il est possible que je fasse un mélange entre ce que je comprends et la solution que vous me proposez, mais telle que je la voit dans l'immédiat, cette dernière me semble moins.... Comment dire... facile à manipuler que si j'avais un vecteur de vecteur.
Après, comme je le disait dans mon précédent post, il est toujours possible de réaliser une structure dédiée qui ne viendrait pas impacter les performances tout en permettant de manipuler un vecteur unique ; d'autant plus qu'il est envisageable de pré-traiter ce vecteur avant utilisation... Bref, je me pencherais plus en détail sur ce sujet une fois que j'aurais mis en place un moyen d’exécuter le code correctement sous windows.


@jo_link_noir : j'ai activé le -pg pour voir si, par le plus grand des hasards, le profiler ne m'affichais pas quelques éléments "anormaux". Il s'avère qu'à par réduire le temps de compilation, il ne m'apporte pas grands choses ici. Dans tous les cas, la version gcc du Mingw32 fourni dans la dernière mouture de code-blocks est la 5.1.0 (visiblement ; sortie de g++ -v).
Quand aux différents flags, j'ai procédé selon tes précisions ; il s'avère que -fsanitize=address me ressort pas mal d'erreurs à la compilation (undefined _asan_before_dynamic_init blablabla... J'en ai toute une flopée comme ça). La sortie est identique en ajoutant -static-libasan au linker... Si maintenant je remplace "address" par "undefined", j'ai le même retour que posté précédemment. Une erreur dans le fichier "formatter.h" et un "internal compiler error". Tous les autres flags proposés n'impactent aucunement la compilation, et la sortie gdb est toujours vierge (GDB v7.9.1).

Existe t'il d'autres compilateurs que GCC, libres, sous windows (et dans la mesure du possible compatibles avec Code::Blocks pour des raisons de "simplicité" type click & run) ? Car si le problème ne vient que de là, je saurais quoi faire...

Merci encore.

[jo_link_noir]

-fsanitize=address doit également être présent dans la phase de link.

Existe t'il d'autres compilateurs que GCC, libres, sous windows ?

Clang, mais je ne sais pas où se trouvent les distributions pour windows.
Sinon, la version 5 de gcc prend de l'âge: https://nuwen.net/mingw.html (v8.2)

Si GLIBCXX_DEBUG ne balance aucune assertion, ce n'est au moins pas un dépassement dans les conteneurs (avec std::vector::operator[] en tout cas).

En fait, tu n'affiches bien que des caractères visibles ?

[koala01]

Pour MinGW, si tu va directement sur la forge, et que tu clique sur le bouton de téléchargement, tu obtiendras un installateur automatique qui te permettra de récupérer, à l'heure actuelle, n'importe quelle version de Gcc juqu'à la version 8.1, en 32 bits ou en 64 bits, utilisant les threads windows ou posix (pthread), et de choisir le système d'exceptions utilisé selon l'architecture choisie (en tout cas pour la dernière).

Rien ne t'empêche d'utiliser la version que tu auras installée grâce à cet outil avec Code::Blocks; il "suffit" d'en indiquer le chemin d'accès dans les options du compilateur, dans le menu settings->compiler, l'onglet "toolchain executable"

(NOTA : si l'idée est d'utiliser ou de compiler Qt toi-même, la version thread posix seh est requise )

Dans le pire des cas, il te reste toujours la possibilité d'utiliser msys2 pour compiler ta propre chaines d'outils (binutils + Gcc + runtime MinGW + "autres bibliothèques") dans les versions que tu souhaites, et pouvoir utiliser Gcc 9.x. Mais cela prend généralement un temps bête à faire

[BioKore]

sortie si -fsanitizeest présent dans les options de compilation :

Code :

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

1
2
C:\Program Files (x86)\CodeBlocks\MinGW\lib\gcc\mingw32\5.1.0\include\c++\debug\formatter.h||In member function 'const __gnu_debug::_Error_formatter& __gnu_debug::_Error_formatter::_M_integer(long int, const char*) const':|
C:\Program Files (x86)\CodeBlocks\MinGW\lib\gcc\mingw32\5.1.0\include\c++\debug\formatter.h|390|internal compiler error: in pp_format, at pretty-print.c:611|

sortie si -fsanitizeest présent dans les options de link :
mingw32-g++.exe: error: libsanitizer.spec: No such file or directoryCeci explique t'il cela ?

Normalement, je n'affiche, à l'écran, que des caractères de type "char" et visibles. Attention par contre, la valeur des pixels qui sont récupérés dans le IDX et stockés dans le vecteur de unsigned char sont eux des valeurs comprises entre 0 et 255 comme précisé dans mon premier post, et les tests sont effectués sur leur valeur absolue (en fait l'uint8_t c'est juste pour n'avoir à adresser que 8 bits par valeur plutôt que 16 ou plus compte tenu que les valeurs sont comprises uniquement dans l'intervalle [0 ; 255]).

@koala01 : bien vu pour l'outil proposé par la forge.... Cependant, c'est avec ce dernier que j'ai fait mes premières compilations sans résultat. Maintenant que j'y pense, comme j'avais déjà pris la dernière version à l'époque avec cet outil, il est tout à fait possible que le bug vienne d'autre chose que la version de GCC... Sortie obtenue :

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
Printing picture of index 5
Label : 1
 
 
 
 
 
                xxxx
               xxxxx
               xxxxx
              xxxxx
              xxxx
              xxxx
              xxxx
             xxxx
             xxxx
             xxxx
            xxxx
            xxxx
            xxxx
           xxxx
           xxxx
           xxxx
           xxxx
          xxxx
          xxxx
           xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Printing picture of index 6
Label : 4
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
Process returned 0 (0x0)   execution time : 12.278 s
Press any key to continue.

On voit que l'index 5 censé représenté un 1 n'est pas complet ; et l'index 6 censé représenté un 4 est quelque peu erroné.


Je vais voir si je trouve du clang ou autre chose. Sinon ben... Je ne compte pas blinder mon windows d'outils linux, donc il est possible que j'installe directement Linux ce week-end si je ne trouve rien de mieux.
A voir si je peux compiler des exécutables windowsiens sous Linux (très certainement mais j'ai jamais fait) ; je ferais des tests comme ça sous VM.

[BioKore]

Ok... Alors à partir de maintenant c'est vraiment bizarre ; même compilé avec MSVC2019 (donc pas avec GCC ni MingW32/64) je me retrouve avec la même sortie.

Je me demande vraiment ce qui cloche du coup. Pourquoi ce même code marche correctement sur Linux et pas Windows ??? Est-ce un problème de dll, d'architecture par défaut (x86/64) ou encore les bibliothèques employées ? En tout cas, visiblement, ce n'est pas le compilateur qui est à remettre en cause.

Je viens de re-tester, sur une VM, sous Linux, avec exactement le même code. Je confirme que le code fonctionne parfaitement sous Linux après un fresh-install.

Décidément, il ne me reste qu'à abandonner totalement Windows...

[Médinoc]

On va commencer par les bases que je n'ai pas vues mentionnées dans ce thread: ton fichier, tu l'ouvres bien en mode binaire?

[BioKore]

Salut ;

Merci pour ce retour, mais qu'entends-tu par "ouverture en mode binaire" ?
Si c'est au mode d'ouverture (dans le code) que tu penses, je l'ouvre comme suivant :

Code :

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

std::fstream sFile(path.c_str(), std::fstream::in);

le fstream récupéré est celui transmit aux fonctions dont j'ai donné le code un peu plus haut.

EDIT : pour info, si je l'ouvre avec l'option std::fstream sFile(path.c_str(), std::fstream::in, std::fstream::binary), le résultat est exactement le même.
EDIT2 : vu ci-dessus, l'option était mal renseignée ; c'est pas avec une ',' qu'il faut séparer les options mais avec '|' !!! Depuis, ça fonctionne !
Merci donc à Médinoc qui a vu juste au premier coup ! Je penserais aux modes d'ouverture la prochaine fois !!!
Néanmoins, la question subsiste : pourquoi des fonctionnements différents entre Linux et Windows ? Simplement car les fichiers binaires sont traités différemment entre les deux OS...

Dans le cas contraire, qu'entends-tu par "ouverture en mode binaire" ?

Merci;

[koala01]

Néanmoins, la question subsiste : pourquoi des fonctionnements différents entre Linux et Windows ? Simplement car les fichiers binaires sont traités différemment entre les deux OS...

Hé hé... Parce que, quand tu ouvre un fichier en mode texte, chaque byte qu'il contient est interprété comme s'il s'agissait d'un caractère de la table ASCII.

Manque de bol, les 32 premiers caractères (ceux qui présentent les valeurs comprises entre 0 et 31 inclus) correspondent à des instructions que l'on pouvait transmettre au "telex" pour leur permettre de formater plus ou moins le texte.

Et, manque de bol, windows et linux n'utilisent pas la même séquence de caractères pour représenter la fin de ligne : windows utilise CRLF (Carriage Return (caractère 13) + Line Feed (caractère 10) ) alors que linux utilise tout simplement CR (Carriage Return (caractère 13) ). Quand tu utilises '\n' en C++ pour indiquer un retour à la ligne dans un fichier texte, cet unique caractère sera automatiquement transformé en CR sous linux et en CRLF en sous windows.

Or, les bytes de ton image représentent des niveaux de gris, et peuvent repésenter n'importe quelle valeur comprise entre 0 et 255, si bien qu'il se peut parfaitement que l'un de ces bytes (ou plusieurs) prenne une valeur comprise entre 0 et 31 inclus, avec une mauvaise interprétation à la clé si le fichier est ouvert en mode texte

[Médinoc]

Cette distinction provient d'un détail qui nous vient des machines a écrire, en passant par les imprimantes "texte" et les télétypes.
Ce détail, c'est que sur les machines à écrire (et nombreuses choses y ayant succédé, y compris au niveau logiciel/réseau comme le protocole HTTP), un retour à la ligne est composé de deux actions: Le retour au début de la ligne actuelle (Carriage Return) et le passage à la ligne suivante (Line Feed). Dans un fichier texte, cela se traduisait par les deux caractères ASCII CR (n°13) et LF (n°10).
Puis furent créés des systèmes d'exploitation déviant de ce standard: Certains comme UNIX (enfin, un de ses ancêtres) n'utilisent que le caractère LF, d'autres comme les anciens MacOS n'utilisent que le caractère CR.

En réponse, lorsque le langage C fut créé, ses concepteurs ont décidé de faire abstraction des différents retours à la ligne: Sauf mention contraire, lorsqu'un fichier est lu, la séquence de retour à la ligne correspondant au système d'exploitation sur lequel tourne le programme est systématiquement remplacée par le caractère '\n', ou "new line" (qui est en fait le même caractère que LF). En écriture, ça fait la transformation inverse:

• Sous Windows, ça veut dire que les CR+LF ("\r\n") sont remplacés par LF ("\n") lors de la lecture; et lors de l'écriture, un CR est inséré avant chaque LF que le programme écrit.
• Sous UNIX et ses dérivés, ça veut dire que LF est remplacé par... LF. Donc, aucun changement.
• Sous un vieux MacOS, ça veut dire que CR est remplacé par LF lors de la lecture, et inversement.

Lorsque ce remplacement est indésiré, on doit ouvrir le fichier en mode binaire (c'est ça, la "mention contraire" qui dit de ne pas faire de conversion). Les langages C et C++ font tous deux cette distinction.

Mais vu que sous UNIX et compagnie il n'y a aucune différence visible entre les deux modes, beaucoup (trop!) d'auteurs de programmes ne pensent pas à ouvrir le fichier en mode binaire pour des manipulations qui nécessiteraient de le faire.

[BioKore]

D'accord ! Je pensais que la problématique était plus subtile que ça. Je connais bien le problème des fameux crlf vs lf entre windows et systèmes unix ; c'est d'ailleurs l'une des incompatibilités les plus emm*****tes lorsque je souhaite, pour différentes raisons, éditer un fichier de conf linux sous windows... Je n'aurais jamais pensé que ce détail était ce qui poserais cette problématique.

Merci pour ces précisions très utiles ! J'ajouterais donc désormais systématiquement cette fameuse option binary lorsque je traiterais d'autres documents que du texte.


Merci bien !

[Médinoc]

Franchement, je reproche aux conceptyeurs du C et du C++ d'avoir décidé que "mode texte" serait choisi "par défaut".
C'est encore pire en C++, où le mode "binaire" a vraiment été rajouté en "afterthought":

1. Il n'y a pas de classe dédiée pour les flux binaires: On se retrouve à devoir utiliser les flux texte, et même leurs fonction read et write traitent des caractères (basic_?stream<>::char_type) plutôt que des bytes
2. À ce qu'on m'a dit, en fait il ne suffit pas d'ouvrir un fichier en mode binaire pour garantir qu'il n'y aura aucune manipulation; il faut aussi imbue le stream avec une locale spécifique (ce message suggère std::locale::classic()).
3. Le standard C++11 a rajouté des générateurs de nombres aléatoires, qui peuvent être sérialisés... en tant que texte uniquement.