Discussion :

[cogidis]

Bonjour à tous,

Un problème à s'arracher les cheveux... J'ai l'habitude de programmer en C++ avec vi et g++ sous Linux (oui, je sais, il y a mieux que vi...), et j'ai réalisé un petit programme qui marche impeccable sous Linux. J'ai voulu le passer sur Visual C++ sous Windows, tout compile mais il ne veut pas m'ouvrir ou lire un fichier avec fstream sauf si je code le chemin en dur dans le code. Impossible de le stocker dans un char *. Exemple :

Cas qui marche :

Code :

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

1
2
ifstream fichier("C:/Users/Jerome/Documents/Visual Studio 2015/Projects/quiutilise/Debug/quiutilise.log", ios::app | ios::binary);
	if (!fichier) { etc. pas exécuté, tout fonctionne}

Cas qui ne marche pas :

Code :

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

1
2
3
4
char endur[200] = "C:/Users/Jerome/Documents/Visual Studio 2015/Projects/quiutilise/Debug/quiutilise.log";
 
ifstream fichier(endur, ios::app | ios::binary);
	if (!fichier) { etc. exécuté, il ne reconnaît pas le chemin !}

J'ai tout essayé, les chemins relatifs avec juste "quiutilise.log", de remplacer les "/" par des "\" et des "\\", de protéger les espaces avec "\ ", bref, j'ai essayé à peu près tout, mais autant ça marche parfaitement sous Linux, autant, sous Windows, il n'accepte que le chemin en dur et pas dans une variable (sauf que ça doit être dans une variable car après je vais lire le chemin depuis un fichier).

Merci pour votre aide.

Jérôme.

[bacelar]

Le message d'erreur, SVP.

[Matt_Houston]

As-tu inspecté le contenu du bloc mémoire avant d'en passer l'adresse au constructeur d'ifstream ? As-tu reproduit ce comportement avec un programme minimal ?

[ternel]

As-tu essayé d'utiliser un const char* plutôt qu'un char[] d'une taille arbitraire? (A tout hasard, on ne sait jamais.)

Et surtout, pourquoi ne pas passer par une std:string? (et sa fonction c_str(), si tu ne compiles pas en C++11)

[Pyramidev]

Chez moi, le code suivant s'exécute sans problème :

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
// Testé avec GCC 6.3.0 sur Windows 7
 
#include <iostream>
#include <fstream>
 
int main()
{
	{
		std::ifstream ifs1("C:/test/test.txt", std::ios::app | std::ios::binary);
		if(!ifs1) {
			if(ifs1.bad())
				std::cout << "ifs1 : bad\n";
			else
				std::cout << "ifs1 : fail\n";
		}
		char c1;
		ifs1 >> c1;
		std::cout << "ifs1 : lecture d'un caractere : " << c1 << '\n';
	} // fermeture de ifs1
 
	{
		char fileName[] = "C:/test/test.txt";
		std::ifstream ifs2(fileName, std::ios::app | std::ios::binary);
		if(!ifs2) {
			if(ifs2.bad())
				std::cout << "ifs2 : bad\n";
			else
				std::cout << "ifs2 : fail\n";
		}
		char c2;
		ifs2 >> c2;
		std::cout << "ifs2 : lecture d'un caractere : " << c2 << '\n';
	} // fermeture de ifs2
 
	return 0;
}

Le mieux serait d'essayer de reproduire le bogue avec un bout de code simple.
Ensuite, tu peux nous montrer le bout de code.

Remarque : std::ios::app (app comme append), c'est pour écrire à la fin du fichier. Ça ne sert à rien avec un std::ifstream.

[cogidis]

Bon, merci à tous pour vos remarques, je m'en suis inspiré, j'ai mis un const, j'ai initialisé la chaine sans réservation, j'ai copié le code dans un nouveau projet, ça faisait pareil jusqu'à ce que... à un moment, je ne sais pas pourquoi, Visual studio m'a proposé de convertir les retours chariots Unix du code en retours chariots de type Windows (\r\n de mémoire). Et là, pouf, ça s'est mis à marcher ! Je pouvais toujours changer le code, c'était bêtement le passage de Linux à Windows qui fait qu'en manipulant des chaînes de caractères, il y avait des caractères que Visual studio ne comprenait pas.

Merci encore.

Jérôme.

[cogidis]

En fait, j'ai juste avancé d'une étape, je peux le mettre en dur dans le code, mais si je le lis le chemin complet depuis un fichier texte passé en paramètre, rebelote, il n'accède plus au fichier.

Quand je fais un affichage, ça a l'air parfaitement similaire :

C:/Users/Jerome/Documents/Visual Studio 2015/Projects/quiutilise/Debug/quiutilise.txt
C:/Users/Jerome/Documents/Visual Studio 2015/Projects/quiutilise/Debug/quiutilise.txt

(c'est le résultat d'un cout de mon const char * en haut avec lequel on peut lire le fichier via un ifstream, et la deuxième ligne celle qui passe par une autre variable char* et qui ne passe pas.

Il doit y avoir une fin de caractère cachée qui fait qu'il n'accède pas au fichier. J'ai essayé de le convertir en ANSI avec Notepad++, en UTF8... En const char*, c'est bon, mais en le lisant depuis un fichier et avec un strcpy dans un char*, ça ne passe plus !

Avez-vous des idées ?

[ternel]

Encore une fois, et std::string?

[koala01]

Salut,

De manière générale, il faut savoir que la plupart des "bonnes" pratiques issues du C sont exécrables en C++.

C'est, en tout état de cause, surtout le cas de celle qui consiste à utiliser un char[] (ou un char * str ="ceci est une chaine de caractères", qui fonctionne aussi) lorsqu'il est question de représenter une chaine de caractères!

Si tu veux commencer à coder correctement en C++, il est tout doucement temps de perdre la plupart des habitudes issues du C afin de les remplacer par celles qui te faciliteront la vie en C++. Et celle dont je parle ici consiste à ... utiliser la classe qui est spécifiquement prévue pour représenter les chaines de caractères en C+ : la classe string, fournie dans l'espace de noms std (comme tout ce qui a trait à la bibliothèque standard) par simple inclusion du fichier d'en-tête <string>, ainsi que ternel te l'a déjà fait savoir par deux fois.

Ainsi, si tu remplaçais ton code par quelque chose de proche de

Code :

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

1
2
3
4
5
// !!!!   C++11 ou ultérieur requis !!!!
std::stirng  endur{"C:/Users/Jerome/Documents/Visual Studio 2015/Projects/quiutilise/Debug/quiutilise.log"};
 
ifstream fichier(endur,ios::binary);
	if (!fichier) { etc. exécuté, il ne reconnaît pas le chemin !}

avec un compilateur acceptant la norme C++11 (ou ultérieur), tu t'éviterais bien des soucis.

Bien sur, si tu ne peux pas disposer de C++11 (ce qui serait vraiment dommage pour un nouveau projet, car, cette norme date quand même de plus de six ans!!!) il faudrait sans doute le modifier pour qu'il prenne plutôt une forme proche de

Code :

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

1
2
3
4
5
// !!!!   C++11 ou ultérieur requis !!!!
std::stirng  endur{"C:/Users/Jerome/Documents/Visual Studio 2015/Projects/quiutilise/Debug/quiutilise.log"};
 
ifstream fichier(endur.c_str(),ios::binary);
	if (!fichier) { etc. exécuté, il ne reconnaît pas le chemin !}

Mais, quand on pense que même la dernière norme acceptée (C++14) est maintenant disponible depuis plus de 3 ans, et que tous les compilateurs récents (depuis Gcc-4.9, et depuis VisualStudio 2015) supportent cette norme, je ne peux m'empêcher que ce serait péché que de ne pas l'utiliser, au vu des possibilités qu'elle nous offre de développer de manière bien plus sécurisante, sans imposer un "overhead" supérieur à celui que les anciennes techniques nous auraient obligés à imposer pour atteindre le même niveau de fiabilité

[ternel]

je souligne consciencieusement le "pour un même niveau de fiabilité"

[koala01]

je souligne consciencieusement le "pour un même niveau de fiabilité"

Ben, tu sais, la fiabilité, ca peut tout simplement être de ne pas laisser passer de fuites mémoire ou d'éviter un débordement de tampon

Ce genre de fiabilité n'a quasiment aucun cout en terme de performance (il "suffit" de s'assurer que delete soit appelé au bon moment pour le premier), mais est particulièrement difficile à mettre en place si on n'adopte pas une politique stricte de respect du RAII. Et std::unique_ptr fournit tout ce qu'il faut pour imposer un tel respect

Maintenant, on peut jouer au développeur java et s'en foutre royalement de fournir des application boguées, qui bouffent de la mémoire "en veux tu? en voilà!" ou qui ne supportent pas que l'utilisateur soit distrait en introduisant une information nécessaire à l'application... Mais ca ne fait vraiment pas partie de mon caractère, car j'aime beaucoup trop le travail bien fait (et je présumes -- peut être à tord -- que c'est ce qui motive la plupart des développeurs C++ à persévérer dans un langage qui reste malgré tout beaucoup plus complexes que ses concurrents )

[cogidis]

A ma grande honte, je dois avouer que je ne connais pas std::string. En fait, j'avais développé une classe de chaine dynamique, je peux faire ce que je veux ou presque, utiliser des "=", des "+" entre 2 chaines, et une cinquantaine d'autres fonctions pratiques. Une de ces fonctions me retourne en chaine de type char * ma chaine dynamique. Et c'est cette classe qui me permet de charger en fichier facilement (ex : dynachaine < "/home/qqpart/monfichier.txt"), et idem en sortie, ou encore de lire ligne par ligne un fichier.

A force de faire mes tests, j'ai trouvé l'erreur, c'est le 86ème caractère de la première ligne de mon fichier .ini qui, malgré mes efforts, contient un caractère non affiché qui correspond à une fin de ligne invisible, probablement en format UTF8. A l'affichage, c'est invisible (cf. mon précédent post). Je vais traquer le code ascii de ce caractère et le supprimer à chaque fois que j'en trouve. C'est pénible !

Merci encore d'avoir pris le temps de regarder. Je passe en résolu je me suis fait une fonction pour supprimer les retours chariots intempestifs.

[koala01]

A ma grande honte, je dois avouer que je ne connais pas std::string. <snip>

Tu fais bien d'avoir honte!!!

J'espère que tu auras suffisamment honte que pour t'intéresser un peu à cette classe (allez, je vais être sympa, voici la doc qui s'y rapporte) et que à virer "le plus rapidement possible" la "roue carrée" que tu as sans doute redéveloppée

Je ne doute pas que tu aies tout fait pour développer ta dynachaine le mieux possible, mais je sais aussi par expérience qu'il y a une quantité phénoménale de pièges auxquels on ne pense pas forcément de prime abord (ni même en seconde approche, d'ailleurs), si bien que je ne peux que mettre la qualité de cette classe en doute (je suis du genre sceptique, et je m'en excuses )

Mais dis toi que ce travail t'auras sans doute permis d'apprendre quelque chose au passage, même s'il s'avère inutilisé au final

[cogidis]

Bon, merci pour la doc, j'ai regardé la classe, elle fait pas mal de fonctions que font la mienne et a l'air très sympa. La mienne, je l'ai développée il y a 19 - 20 ans (je ne sais pas si la classe std::string existait à l'époque), et entretenue et améliorée au fur et à mesure. C'est une liste simplement chaînée avec une mémoire cache (pour ne pas parcourir toute la liste sachant qu'on fait souvent appel aux caractères qu'on vient de lire ou modifier, et ne pas faire une liste doublement chainée, ça commence à faire lourd en mémoire sinon, car pour 1 caractère on a le précédent et le suivant à stocker, soit 9 octets en 32 bits... et 17 octets en 64 bits ! Et si on a de l'utf8 dedans, certains caractère prennent 2 positions, donc on alourdit encore l'occupation mémoire).

Ceci dit, ça me sert beaucoup; Là, je viens de créer une méthode supprime_retours_chariots-windows(). J'ai aussi une autre méthode qui me convertit de l'UTF8 au latin1, etc.

Mais du coup, si je veux lire un fichier et modifier quelque chose dedans, je fais :

Code :

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

1
2
3
4
Dynachar d;
d < "/home/quelquepart/monfichier.txt";
d.remplacepartout ("Bonjour","Au revoir");
d> "/home/quelquepart/monfichier.txt";

Et voilà, pour remplacer bonjour par au revoir dans un fichier, c'est fini ! J'ai encore pas mal d'opérateurs de conversion (en entiers, en double, etc. en char *, etc.), des opérateurs comme std::string, d'insertion, de simplification (me remplace les caractères accentués commes les "à" en a, les majuscules en minuscules, etc. Donc typiquement, je m'en sert pas mal pour faire des fichiers de configurations, je lis, je triture, j'écris des résultats en sorties, etc.

Jérôme.

[ternel]

Donc, tu es tombé dans le travers décrié de std::string: trop de méthodes qui pourrait être des fonctions libres, voire des algorithmes plus généraux.
De plus, ton implémentation est très gourmande en mémoire. Tu devrais pouvoir l'améliorer avec une std::deque, si tu veux la garder, voire un std::vector.

[koala01]

Bon, merci pour la doc, j'ai regardé la classe, elle fait pas mal de fonctions que font la mienne et a l'air très sympa. La mienne, je l'ai développée il y a 19 - 20 ans

Bon, allez, tu es pardonnable et pardonné (d'avoir créé ta propre classe, en tout cas)

(je ne sais pas si la classe std::string existait à l'époque),

Humm... sauf erreur, la bibliothèque standard (incluant std::string) a été acceptée (et il en existait une version disponible sur internet) avec C++98... A toi de voir de quand date ta première implémentation.

et entretenue et améliorée au fur et à mesure.

Ca mérite certainement un grand coup de chapeau

Mais, je ne peux m'empêcher de regretter le manque d'intérêt pour la bibliothèque dont témoigne cette phrase... D'ici à ce que tu me dise que tu as des classes équivalant à std::vector, std::list, std::set ou std::map, il n'y a qu'un pas, et je serais vraiment décu si tu venais à me confirmer que tu les a.

C'est une liste simplement chaînée avec une mémoire cache (pour ne pas parcourir toute la liste sachant qu'on fait souvent appel aux caractères qu'on vient de lire ou modifier, et ne pas faire une liste doublement chainée, ça commence à faire lourd en mémoire sinon, car pour 1 caractère on a le précédent et le suivant à stocker, soit 9 octets en 32 bits... et 17 octets en 64 bits ! Et si on a de l'utf8 dedans, certains caractère prennent 2 positions, donc on alourdit encore l'occupation mémoire).

Rien que pour cela, tu devrais commencer à t'intéresser à std::string, car son "surpoids" est de bien moindre

Ceci dit, ça me sert beaucoup; Là, je viens de créer une méthode supprime_retours_chariots-windows().

Humm ca ne devrait pas être son role, car, quel que soit la manière dont est effectivement représenté un retour chariot avec les différents système d'exploitation, il devrait être représenté, au niveau de ta chaine de caractères, de manière uniforme ('\n', et rien d'autre)

J'ai aussi une autre méthode qui me convertit de l'UTF8 au latin1, etc.

(très) intéressant, mais tu donne une responsabilité à ta classe qu'elle ne devrait

Mais du coup, si je veux lire un fichier et modifier quelque chose dedans, je fais :

Code :

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

1
2
3
4
Dynachar d;
d < "/home/quelquepart/monfichier.txt";
d.remplacepartout ("Bonjour","Au revoir");
d> "/home/quelquepart/monfichier.txt";

Et voilà, pour remplacer bonjour par au revoir dans un fichier, c'est fini ! J'ai encore pas mal d'opérateurs de conversion (en entiers, en double, etc. en char *, etc.), des opérateurs comme std::string, d'insertion, de simplification (me remplace les caractères accentués commes les "à" en a, les majuscules en minuscules, etc. Donc typiquement, je m'en sert pas mal pour faire des fichiers de configurations, je lis, je triture, j'écris des résultats en sorties, etc.
[/QUOTE]
Je confirme que ca mérite vraiment le respect, mais, comme le fait que tu l'as entretenue pendant près de vingt ans sous-entend que tu ne t'es sans doute pas intéressé à ce que la bibliothèque standard (dont une grande partie a le même âge, à peu de choses près) modère très largement l'ardeur que je pourrais éprouver à te le témoigner

[cogidis]

J'ai appris le C++ standard à l'IUT, mais depuis je ne regarde pas les nouveautés, mon niveau a à peine monté, je fais principalement du système et des réseaux. Je crée plus facilement que je ne fais de la veille technologique en C++ ! Ma classe me sert à manipuler des fichiers textes, ma dernière réalisation en date est de récupérer un journal de banque au format OFX et de le transformer pour l'intégrer en fichier directement importable par Quadracompta. Gain de temps énorme par rapport à une saisie manuelle, et soldes toujours 100% exact.

Je n'ai pas refais les autres classes rassure-toi. Les caractères de fin de fichier ou le passage en ANSI / Latin1 en UTF8 ou vice-versa viennent du fait que j'ai des fichiers textes parfois générés sous Linux, parfois sous Windows et que je remplis mes chaines avec ça tel que ça vient.

L'occupation mémoire ne me gêne pas, même en ouvrant des fichiers de plusieurs Mo pour le charger dans une dynachaine (c'est rare), vu les tailles mémoires dont on dispose maintenant, ça n'est pas gênant. Et pour l'usage que j'en fais, en général j'ai le résultat à peu près en même temps que le retour chariot, donc au niveau performances, ça va vite (surtout en cas de suppression ou changements, je ne réalloue pas un nouveau char * à chaque fois, c'est vraiment caractère par caractère que c'est alloué. Mais effectivement, std::String doit être au moins aussi efficace, et probablement plus performante dans la majorité des cas (mais certainement pas tous).

J'ai aussi des traitement par lignes (méthode nblignes(), ou ligne[n] qui retourne la ligne n, supprimeligne (n)). J'ai des méthodes qui compte les caractères, qui retournent les nombre de remplacement, etc. Bref, un couteau suisse pour charcuter les fichiers texte et typiquement faire des fichiers de paramètres, ou des traitements automatiques, par exemple sur du html.

[JolyLoic]

L'occupation mémoire ne me gêne pas, même en ouvrant des fichiers de plusieurs Mo pour le charger dans une dynachaine (c'est rare), vu les tailles mémoires dont on dispose maintenant, ça n'est pas gênant. Et pour l'usage que j'en fais, en général j'ai le résultat à peu près en même temps que le retour chariot, donc au niveau performances, ça va vite (surtout en cas de suppression ou changements, je ne réalloue pas un nouveau char * à chaque fois, c'est vraiment caractère par caractère que c'est alloué. Mais effectivement, std::String doit être au moins aussi efficace, et probablement plus performante dans la majorité des cas (mais certainement pas tous).

Je pense qu'en terme de fonctionnalités, ta classe doit être très bien adaptée à ce que tu fait, et battra probablement std::string. Par contre, à lire la description que tu en fais, je pense qu'en terme de performances, std::string te met minable Pas forcément sur chaque opération isolée, mais sur l'ensemble d'un programme, j'ai de gros doutes sur ton implémentation.

Donc, si tu as des perfs suffisantes par rapport à ce que tu fais, et que tu es seul à bosser sur ton code, continue à utiliser ta classe, elle convient tout à fait. Maintenant, si tu as un bout de code où la perf n'est pas assez bonne, je te conseille de regarder vers std::string !