Discussion :

[mioux]

Bonjour à tous

J'ai installé MinGW sur un poste sous Windows, et je suis confronté à un problème cornélien.

J'ai une série de fichiers que je dois traiter très rapidement (d'où le choix de C/C++ par rapport à C# que je maitrise mieux, mes cours de C/C++ datent, et n'étaient pas très avancés, c'était plus de la méthode de développement que l'apprentissage d'un langage)

Le but est de retirer toutes les lignes vides de ces fichiers (sachant qu'il risque y avoir d'autres traitements plus tard, mais pour le moment je me concentre là dessus).

En entrée, j'ai des fichiers issus de systèmes d'informations Un*x ou Windows, où les fins de lignes ne sont pas codées de la même manière (CR-LF pour les systèmes Windows, LF seul pour les systèmes Un*x)

Sachant que je ne peux pas demander à tous mes clients de changer leurs fichiers (j'optimise de l'existant, et leur faire changer coûterais trop cher et serait trop long), que mon programme tourne sous Windows, et qu'il faut que je respecte le format de fichier original sans les lignes vides, je me suis dit "Tiens, je vais faire un petit programme en C qui va lire un fichier ligne par ligne, puis le réécrire dans un autre fichier en ignorant les lignes vides"

Seulement dans ma tête, '\n' était l'octet LF et '\r' l'octet CR. Donc je me suis dit : "Dans un premier temps, je réécris mes lignes avec endl, puis ensuite, je ferais une détection du caractère de fin de fichier, et j'aviserais en fonction"...

Sauf que grave erreur de ma part, je ne savait pas que '\n'... c'est CR-LF sous Windows...

Ma question est "simple"... comment je peux faire pour écrire dans un fichier un caractère LF sans CR ?

J'ai tenté avec un ofstream

Code :

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

1
2
3
4
ofstream outFile ("mon-fichier.txt");
outFile << buffer << endl; // CR-LF
outFile << buffer << '\n'; // CR-LF
outFile << buffer << (char)10; // CR-LF << celui là m'étonne

Et également avec un FILE *

Code :

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

1
2
3
4
5
6
7
FILE *outPtr = fopen("mon-fichier.txt", "w");
unsigned char *eol = (unsigned char *) malloc (2 * sizeof(char));
eol[0] = 10;
eol[1] = '\0';
 
fwrite(buffer.c_str(), 1, buffer.size(), outPtr);
fwrite(eol, 1, 1, outPtr); // CR-LF << Je suis étonné également

Une fois que j'aurais compris comment écrire un LF seul, je pourrais continuer en détectant mon caractère de fin de fichier, pour le moment, je bloque là dessus... chaque problème en son temps

Bien entendu, le code ci dessus est très sale, le vrai code gère les erreurs d'ouverture de fichiers, les pointeurs alloués à NULL, les fermeture de fichiers et la libération des pointeurs

[Lavock]

Mettre ton fichier au format binaire ira ?

[mioux]

Si au final mon fichier est correct, oui, mais le mode "b" n'est pas ignoré dans gcc > 3 ?

[Lavock]

Que nenni ! En c++ : std::ofstream file("File_Name",std::ios_base::binary);

Et oui, ça marche. J'ai déjà essayer d'écrire une image en mode texte, les résultats étaient spectaculaire >< !

[mioux]

Merci, c'est génial...

un simple "wb" et c'était réglé :'(

La prochaine fois, je teste avant de croire ce que je lis sur le net

(oui j'ai pas trop l'habitude d'utiliser les ofstream, pour dire, j'ai découvert la classe string en regardant la FAQ... en cours on nous avait fait développer une classe lstring basée sur du char * pour créer notre propre chaine de caractère... et on n'utilisais que du FILE * pour manipuler des fichiers ^^)

[koala01]

Salut,

Merci, c'est génial...

un simple "wb" et c'était réglé :'(

La prochaine fois, je teste avant de croire ce que je lis sur le net

(oui j'ai pas trop l'habitude d'utiliser les ofstream, pour dire, j'ai découvert la classe string en regardant la FAQ... en cours on nous avait fait développer une classe lstring basée sur du char * pour créer notre propre chaine de caractère... et on n'utilisais que du FILE * pour manipuler des fichiers ^^)

Voilà bien de très mauvais cours, qui sont, malheureusement, trop fréquents...

Je ne dis pas qu'il n'est pas intéressant de demander aux élèves d'implémenter une classe string "personnelle", car cela permet d'aborder certains détails, mais, par contre, le fait de ne parler ni de la classe std::string ni des flux (en générale) ni des fichiers (en particuliers) me semble... peu engageant pour l'avenir.

A l'heure actuelle, on en est à une situation dans laquelle les gens prennent de plus en plus conscience du fait que, bien que C++ descende en droite ligne de C, il s'agit, malgré tout, d'un langage tout à fait distinct, pour lequel une grande partie des possibilités issues de son "ancêtre" le C sont à éviter autant que possible.

Aussi, si je n'avais qu'un seul conseil à te donner, ce serait bien de te "ruer" sur la FAQ, et de la lire attentivement, d'abandonner les pratiques issues du C et de t'intéresser à ce que C++ peut t'offrir, que ce soit au niveau des flux (de manière générale), de la classe string ou des collections d'objets...

Tu verra, cela te simplifiera énormément la vie et te permettra de fournir un travail bien meilleur

[mioux]

J'ai la "chance" de ne pas travailler en C/C++, là c'est un minuscule projet qui demande une grande réactivité, chose que ne peux pas avoir C# (enfin, je veux dire que le temps passé pour faire la même chose en C# a beau être petit, le C++ offre des performances bien supérieures pour un résultat équivalent)

Quant à mes cours, les profs nous l'ont expliqué eux même, le but n'était pas d'apprendre un langage, mais une méthode de travail. Chose plutôt efficace, puisque, quand je suis arrivé à programmer en C#, en ne connaissant absolument pas le langage, j'avais déjà des réflexes objets. La première chose que j'ai voulu faire, c'est de l'héritage multiple (et comme par hasard, en C#, ca n'existe pas...)

Leur approche est intéressante, on a vu plusieurs méthodes de programmation, dans plusieurs langage, mais vraiment maitrisé aucun.

On a eu des cours d'algorithmique (en Python pour la mise en pratique, car de ce que je me souvient, c'est un peu comme le basic, on dicte ce qu'on veut faire), de programmation itérative (C), de POO (C++, remplacé par Java l'année suivante), et de programmation fonctionnelle et symbolique (LISP)

Au final, on a des bases dans chaque type, les erreurs à éviter, une méthode de réflexion, mais on est pas "bloqués" sur un langage.

J'ai bien aimé cette méthode d'apprentissage, mais elle a des défauts, comme on peut le voir, on avait des outils qui existaient pour faire des choses en C++ mieux qu'en C, et on ne nous les a jamais montrées.

Finalement, en passant un peu par la FAQ, j'ai plus de FILE * (je les avait remis pour mon CR LF, quand j'ai lu dans le man de fopen que l'attribut "b" n'était plus pris en compte), j'ai peu de char * (je les ai gardés par habitude) et vu que j'ai pas grand chose de plus, finalement, je m'en suis sorti

[koala01]

Bien que je m'en veuille de relancer un éternel débat, je dois dire que je comprend ton point de vue mais que je ne le partage pas...

Les techniques de programmation pourraient parfaitement être abordées sans même avoir recours au moindre langage de programmation, et la vérification peut, tout à fait, être faite sur base d'un "jeu de rôle" dans lequel tu te met à la place de l'ordinateur.

C'est, peut être (surement :question), plus un problème d'oganisation du "timing" dans les études, mais il est tout à fait possible d'aborder les méthodes de programmation et de donner "les bons réflexes" les concernant sans avoir à écrire la moindre ligne de code.

En effet, une boucle reste une boucle, un héritage ou une agrégation reste un héritage ou une agrégation, quel que soit le langage envisagé, pour autant qu'il supporte le concept, car un langage n'est jamais qu'une convention qui nous permet de faire comprendre à quelque chose d'aussi bête qu'un ordinateur ce que l'on attend de lui...

Une fois que l'on a ces "bases communes", il est très facile d'apprendre n'importe quel langage, d'y appliquer les bases que l'on a apprises en algorithmique / conception, et donc, de s'intéresser réellement aux capacités et aux facilités que peuvent apporter certains langages particulier.

Je suis tout à fait d'accord avec le fait que les études n'ont absolument pas comme objectif de permettre au élèves de maitriser un langage particulier (et, forcément encore moins, d'en maitriser plusieurs), ne serait-ce que parce que pour réellement maitriser un langage, il faut compter sur plusieurs années d'utilisation plus ou moins intensive, et que, si tel était l'objectif des études, elles dureraient encore beaucoup plus longtemps, et je suis d'accord avec le fait qu'il est plus cohérent d'apprendre un langage séquentiel avant d'apprendre un langage OO, mais il n'en demeure pas moins que, si l'on n'apprend pas "en quoi un langage donné " peut nous aider, les "particularités remarquables" de ce langage et les "problèmes récurrents" que le langage peut engendrer, l'apprentissage d'un langage donné n'a, en définitive, aucun intérêt