Discussion :

[Imad_ing]

Bonjour tout le monde.
Je suis en train de développer une application en C++, et cette application va devoir me sortir comme résultat 3 fichiers plats (TXT):
- Le premier sera pour le résultat du traitement de mon programme
- Le deuxième pour les statistiques
- Le troisième pour le log des erreurs.
Ma question est la suivante:
Est ce que je peux, en toute sécurité, écrire simultanément dans ces trois fichiers? C'est à dire, est ce que je peux, au début de mon programme, localiser mes trois fichiers, les ouvrir en création, et écrire à chaque fois qu'il y a besoin, l'information nécessaire dans le fichier adéquat?
J'ai demandé à droite à gauche, on m'a dit que non, mais ce qui me casse la tête, c'est surtout si la quantité de données que j'aurai à traiter serait trop grande? et aussi si le programme ne trouvera pas de problème à se localiser dans l'un des fichiers à ma demande ?

Une solution qu'on m'a proposé: Créer mes fichiers au début du programme, ne les ouvrir en mode modification qu'en cas de besoin, et les refermer après chaque utilisation.
Est ce que ça n'a pas d'impact sur le temps de traitement? Sachant que la volumétrie de mes données risque d'être trop grande? D'où l'ouverture et la fermeture de mes fichiers serait une tâche à faire et à refaire ?


Merci d'avance pour vos réponse.

[Matthieu Brucher]

Il n'y a aucun problème pour conserver les 3 fichiers ouverts en même temps et à écrire dedans au fur et à mesure.

[Klaim]

Oui, la seule condition c'est qu'il n'y ait pas d'accès concurrentiels (en écriture seulement?). C'est la base pour tout ce qui est "parrallèlisme".

[Imad_ing]

Oui, la seule condition c'est qu'il n'y ait pas d'accès concurrentiels (en écriture seulement?). C'est la base pour tout ce qui est "parrallèlisme".

J'ai pas bien saisi ce que tu veux dire par " Accès Concurrentiels " ?

Pour mes fichiers, je compte les ouvrir tout les trois au début de mon programme en mode création, leurs attribuer un fileName.
Puis, et au fur et à mesure de mon besoin, j'écrirai dans le fichier adéquat l'information souhaité.
Ce n'est qu'à la fin de mon programme que je vais fermer mes trois fichiers.

Merci pour vos réponse, et encore merci pour ton retour Klaim

[poukill]

Je dirai comme Mathieu, aucun problème.
Un problème arriverai par contre si tu écrivais dans un même fichier depuis 2 threads différents. Mais ça n'a pas l'air d'être ton cas.

[Invité]

Bonjour,
Sauf la capacité de la machine, il n'y a pas de limite au nombre de fichiers ouverts, en écriture et/ou en lecture. A condition, naturellement, que le même fichier ne soit pas ouvert plus d'une fois en même temps.
Il y a 2 fonctions qui permettent le contrôle d'état d'un fichier, access() et fstat(), mais leur portabilité n'est pas garantie.
Sous DOS, le nombre de fichiers ouverts en même temps était limité. Pour des applications compliquées, cela pouvait devenir pénalisant.

La quantité de données à écrire est une notion indépendante du nombre de fichier ouverts.
Il ne faut pas fermer un fichier pour une raison autre que celle de ne plus en avoir besoin.
Enfin, n'oubliez pas qu'il y a différents modes d'ouverture des fichiers.
Bon développement.

[Imad_ing]

Super les gars. Voilà pourquoi j'aime ce forum.

Merci beaucoup encore une fois.

[jblecanard]

3 fichiers plats

Merci à toi, je ne connaissais pas l'expression

[Invité]

Bonjour,
Pardon pour cette petite remarque :
Un fichier est une suite de bits. On peut grouper ces bits en octets, et c'est ce qu'on fait généralement.
Un octet correspond à un caractère, pas forcément alphabétique ou numérique (en gros entre 33 et 128 plus éventuellement des caractères accentués, si on connait la table de code).
Qu'est-ce qui distingue un fichier TXT d'un fichier binaire ? réponse l'interprétation des 32 premiers caractères (au moins de certains des 32 caractères et en particulier Fin de Ligne et Retour Charriot : CRLF 0x0D et 0x0A)
Alors la différence d'écriture entre un fichier TXT et un fichier binaire (par exemple un raster ou un .EXE) ne réside que dans le choix d'interprétation de ces caractères de contrôle.

Ceci m'a été provoqué par la très jolie dénomination de fichier "plat" pour un fichier TXT. Appelle-t-on "creux" un fichier binaire?
Cordialement

[Imad_ing]

Mr Pierre Dolez,

Appelle-t-on "creux" un fichier binaire?

Vous auriez du faire cette remarque dès le début de votre intervention pour m'aider à mieux m'exprimer. Mais merci comme même parce que moi au fait, je connaissais pas cette nomination, et je n'ai fait qu'apprendre le terme à travers les gens Métiers (Mes Clients)! Merci encore

Mr jblecanard

Merci à toi, je ne connaissais pas l'expression

Mais de rien! Régales toi mon frère

Mais aujourd'hui, j'ai un autre problème, est c'est pour cela que je vais réouvrir cette discussion: Après avoir parsé mes fichiers XML avec TinyXML, je constitue des lignes dans une chaine de caractères, et chaque ligne est constitué de concaténation de plusieurs données en provenance de plusieurs balises.
Le problème est que lorsque je copie cette chaine de caractère dans mon fichier PLAT de sortie , j'obtient dans mon fichier des caractères genre

Forfait Maitrisé

au lieu d'avoir

Forfait Maitrisé

.
J'ai cherché sur internet, et j'ai trouvé que TinyXML supporte l'UTF8, et la méthode que j'utilise pour copier ma chaine de caractères dans le fichier est :

Code :

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

MonFichier >> MaLigne  >> endl

de la classe ofStream qui dérive de std::ios_base.
Donc ma question est: Quel type de sortie nous offre ofStream ? et y'a t'il une autre méthode pour garder mes caractères tel qu'elles sont sur le fichier XML?

Merci d'avance pour vos réponse.

Cordialement

[Invité]

Bonjour,
Ce type de problème ne date pas d'hier.
La table de caractère comporte 256 cases (de 0 à 255). Les 32 premiers son reservés. Les caractères 33 à 127 sont normalisés.
Par contre, les caractères 128 à 255 sont différents d'un table à l'autre.
Je ne vous donnerai pas la solution, parce qu'à mon avis, elle dépend de pas mal de choses que j'ignore.
Pour que je comprenne mieux il me faudrait plus de détails, par exemple, la chaine que vous appelez "LaLigne" et que vous écrivez, d'où vient-elle ?
Si je craignais les foudres des C++istes, j'arrêterais là.

Essayer de faire une ouverture de fichier "Standard" et une écriture "Standard". On obtiendra certainement la même chose, mais un petit essai ne coûte rien.

Code :

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

1
2
3
4
5
6
7
8
FILE *ecr = fopen("Fichier_essai.txt","wt");
if (ecr)
{
   ...  // création de MaLigne
   fprintf(ecr,"%s\n",MaLigne);
   ... // suite
   fclose(ecr);
}

Cordialement.

[Imad_ing]

Merci tout d'abord pour ta réponse rapide.

Au fait, le but de mon programme est de transformer un fichier XML en un fichier txt. Ce fichier txt a bien une structure à respecter: (L'ordre des information dans chaque ligne commençant par un code spécifique.) Car dans le programme qui va prendre mon fichier txt, lui il lit les informations depuis une position donnée, et sur un nombre défini de caractères.

Voilà un exemple de ligne du fichier txt de sortie que je dois avoir:

MAR100003 FR0300 0101190001011900000000173058

Donc, pour écrire ces données dans la ligne, je dois chercher chaque info à part, vu qu'elles ne se trouvent pas dans le même bloc de mon fichier xml, et les concaténer dans une variable string, et ce pour pouvoir construire ma ligne.

Une fois ma ligne est construite, je la copie dans le fichier txt et j'effectue un retour chariot.

Voilà un exemple de bloc xml d'ou proviennent mes données:

Code :

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

1
2
3
4
5
<ligneResumeClient categorie="" codeItem="MensCo" idBloc="0300">
				<dateDebut>2010-06-01</dateDebut>
				<dateFin>2010-06-29</dateFin>
				<montantHT>432.39</montantHT>
			</ligneResumeClient>

Donc, si vous remarquez bien, dans ce bloc xml, j'ai le code ma ligne qui est

idBloc="0300"

, mais pas toutes les informations qui constituent ma ligne ne se trouve dans ce bloc. ( Il y a d'autres informations en provenance d'autres balises ou d'autres blocs )

Quand je visualise mon fichier, je trouve que les données qui contiennent les caractères accentués sont affichés différemment.

J'espère que ça t'aidera à m'aider

Et merci encore pour tes réponses et tes clarifications.


Cordialement

[Imad_ing]

J'ai oublié un truc

En effet, l'utilisation de fprintf me génère une erreur au niveau de la mémoire.
Lorsque j'exécute, ça retourne une erreur.
Même en faisant le test avec une simple chaine de caractère se composant de 4 caractères, en pensant que fprintf aurait une contrainte sur la longueur des chaines de caractères; mais apparemment ce n'est pas le cas.


Cordialement

[nikko34]

tu as écris en UTF-8 en fait dans ton fichier texte, du coup tu as deux octets pour un caractère.

Si tu veux écrire en ASCII à partir de l'UTF-8, il faut que tu convertisses l'un dans l'autre (bon ça marchera pour le français).

( Sinon Pierre a vite tendance à revenir au C hein! )

[Imad_ing]

Si tu veux écrire en ASCII à partir de l'UTF-8, il faut que tu convertisses l'un dans l'autre

Vous n'auriez pas un exemple ? Car je n'ai jamais fait une chose pareille.

Merci d'avance

[Invité]

@ imad-ing
Je pense que la solution est dans les toutes premières lignes du fichier XML.
C'est là qu'il y a la définition de la table de code utilisée.
Sinon, il y a une solution un peu brutale mais qui a l'avantage de marcher dans tous les cas, c'est de faire une table de correspondance.
Ce n'est pas du tout pénalisant en durée de traitement.
Ca peut être fait sous forme d'un switch:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
for (i=0; i<strlen(ligne); i++)
{
  char c=ligne[i];
  switch(c)
  {
    case 128: ligne[i]=212; break;
    case 129: ligne[i]=221; break;
    case '¤' : ligne[i]='à'; break;
    ....
    default : break;
  }
}

Naturellement les 128, 129, 212, 221 sont au hasard.
La syntaxe de la 3è ligne est aussi correcte et un peu plus claire.

Concernant l"erreur générée par fprintf, il s'agit peut-être de caractères sur 2 octets, mais il s'agit pet-être aussi d'absence de 0 terminal, ce qui expliquerait qu'il y a un caractère de trop dans "Forfait Maitrisé".

@ Niko34
Oui, je l'avoue. Il y a une quinzaine d'années, lorsque je suis passé du C au C++, après avoir bien compris l'utilité des classes, j'ai voulu utiliser iostream qui est à priori un bonne première approche, je n'ai trouvé aucun avantage par rapport à mes fprintf(), fgetc(), fgets(), fread(), fwrite(), et je n'utilise pas cette librairie. Mais comme de toute façon, le C++ est une extension du C on ne peut rien me reprocher.
D'ailleurs, un langage en lui-même n'offre aucun intérêt, c'est le développement qui est intéressant.
Il devrait y avoir une section "Algorithme" dans ce forum.
Mais "faute avouée est à moitié pardonnée".

La théorie des 4 couleurs dit que l'on peut colorier des zones adjacentes, par exemple les départements français en utilisant seulement 4 couleurs et sans que 2 zones adjacentes n'aient la même couleur.
C'est ce type de problème qui m'intéresse, alors, C ou C++, quelle importance?
Cordialement.

[jblecanard]

Bonjour

Il devrait y avoir une section "Algorithme" dans ce forum.

Cela existe mon cher, ici même.

[Invité]

Merci beaucoup, ça, ça m'intéresse.

[nikko34]

(je vais pas revenir sur le débat C <-> C++ qu'on a déjà eu)

Pour passer de l'UTF-8 à Latin 1 ( et pas ASCII en fait ) il faut savoir:

que la taille d'un caractère en UTF-8 peut-être de 1, 2, 3 ou 4 octets.

Le nombre d'octet dépend du premier octet.

Si dans le premier octet le bit de poids fort est 0, alors on aura qu'un seul octet, et cet octet sera équivalent au caractère ASCII.

Si le premier octet est égal à "0xC2" alors le caractère sera codé sur 2 octets et tu peux trouver l'équivalent Latin 1 dans le 2e octet

Si le premier octet est égal à "0xC3" alors l'équivalent Latin 1 sera le deuxième octet plus "0x40".

Et je crois que ça devrait suffire pour le français...

[Imad_ing]

Cool.

Mais que pensez vous de cette bibliothèque ?