Discussion :

[Invité]

Cette réponse dérive du la discussion " Problème lecture d'un fichier de 500 Ko

Mais, par pitié, sur le forum C++, la première chose à faire, c'est de veiller à donner des solutions C++...

Cela signifie que dés que l'on remarque FILE, fread, fwrite, fopen, fclose ou même char* (plus toutes les choses auxquelles je ne pense pas), il faut tirer un signal d'alarme et bien faire comprendre à la personne qu'il travaille en C.

Les lectures à base de FILE sont effectivement des héritages du C, mais tous les compilateurs C++ (que je connais) les reconnaissent, les acceptent, et les fournissent dans leurs bibliothèques standard. Si on va par là, c'est plus standard que Boost...

Quant à char*, quelle drôle d'idée!

FILE appartient au C++, tout comme "football" est un mot français d'origine anglaise. L'utiliser pour lire des fichiers, c'est sans doute pas très standard (comme on parle un français "non standard" dans plein de régions du monde), mais de là à "tirer un signal d'alarme"?

Ca me rappelle ces parisiens qui se moquent des marseillais, ou des québecois, parce qu'ils trouvent qu'ils parlent mal français.

(Et non, je n'utilise pas FILE, je préfère les fstream, et oui je suis parisien).

D'un coté, tu utilises un fichier dont l'extension est en *.txt, ce qui fait penser que tu utilise un fichier considéré comme étant un fichier contenant... du texte (des chaines de caractères, en fait), et de l'autre, tu ouvre ton fichier en mode "binaire", ce qui fait penser que tu souhaite gérer le contenu du fichier comme ... des données brutes...

Mode binaire ou mode texte, ca dépend essentiellement de la façon dont les fichiers sont structurés, pas des données qu'ils contiennent ou de leur utilisation future (et encore moins de leur extension).

En mode texte, on s'attend à voir des lignes de longueur variables, séparées par des retours à la ligne, et parfois des séparateurs intermédiaires. On lit ligne à ligne (ou champ à champ) sans se préoccupper de la position où l'on se trouve, et on fait en général des getline, qui lisent jusqu'au prochain délimiteur. A chaque lecture, ces délimiteurs sont supprimés: l'utilisateur n'y a jamais accès.

En mode binaire, on doit spécifier, à chaque lecture, le nombre d'octets qu'on lit. Ceci est donc adapté à des fichiers où les champs ou les enregistrements sont de longueur fixe (mais qui peuvent parfaitement contenir des chaines de texte). Et on utilisera alors des read. Ces positions fixes permettront également plus facilement de se déplacer dans le fichier sans le lire avec des seekg par exemple.

Le choix entre mode texte et mode binaire ne dépend pas de la nature ou de l'utilisation qu'on va faire des données, mais seulement de la façon dont elles sont organisées dans le fichier. Un grand nombre de fichiers textes sont formattés "en ASCII colonné", et se lisent en mode binaire.

En pratique, la lecture en more binaire est toujours plus rapide que le mode texte: un read n'a pas besoin de contrôler la présence de délimiteurs, on peut allouer ses tailles de structures unitaires de lecture à l'avance, etc...

Et, une fois de plus, ca n'a pas grand chose à voir avec le C: on fera en C++.

Code :

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

ifstream fdat.open("mon_fichier.txt",ios::binary);

Francois

[ptyxs]

Les lectures à base de FILE sont effectivement des héritages du C, mais tous les compilateurs C++ (que je connais) les reconnaissent, les acceptent, et les fournissent dans leurs bibliothèques standard. Si on va par là, c'est plus standard que Boost...

Quant à char*, quelle drôle d'idée!

D'autres que moi, plus expérimentés, répondront sans doute de façon plus élaborée et argumentée. Cela dit, il me semble que tu fais complètement fausse route : si les outils du C sont disponibles en C++ c'est avant tout pour permettre une compatibilité avec du code antérieur existant et en aucune façon parce que cela serait recommandé ou souhaitable de les utiliser dans des programmes nouveaux lorsque ce n'est pas indispensable pour une raison bien précise.
Quant aux pointeurs et tableaux, ils constituent une des difficultés et sources d'erreur majeure du C et un des avantages du C++ c'est de permettre de les éviter dans un grand nombre de cas et de construire ainsi du code plus lisible, plus facile à maintenir et moins 'error-prone', ce qui est un des objectifs majeurs du C++

[JolyLoic]

Les lectures à base de FILE sont effectivement des héritages du C, mais tous les compilateurs C++ (que je connais) les reconnaissent, les acceptent, et les fournissent dans leurs bibliothèques standard. Si on va par là, c'est plus standard que Boost...

L'idée n'est pas de dire que ce n'est pas standard, mais de dire que si le but est de faire du C++, il y a des alternatives supérieures.

[koala01]

Cette discussion a été ouverte comme digression de la question portant sur la lecture de fichier

message original

Les lectures à base de FILE sont effectivement des héritages du C, mais tous les compilateurs C++ (que je connais) les reconnaissent, les acceptent, et les fournissent dans leurs bibliothèques standard. Si on va par là, c'est plus standard que Boost...

Quant à char*, quelle drôle d'idée!

Le fait est que, venant du C, on a vite fait d'assimiler un char* à... une chaine de caractères (comprend: de caractères "imprimables", composée d'un tableau de caractères terminé par '\0')

Je veux pour preuve de cette affirmation la toute récente discussion tableau d'element hexa tronqué qui n'est qu'une illustration supplémentaire (le problème se pose très régulièrement) de la confusion si facile à faire en C

FILE appartient au C++, tout comme "football" est un mot français d'origine anglaise. L'utiliser pour lire des fichiers, c'est sans doute pas très standard (comme on parle un français "non standard" dans plein de régions du monde), mais de là à "tirer un signal d'alarme"?

Ca me rappelle ces parisiens qui se moquent des marseillais, ou des québecois, parce qu'ils trouvent qu'ils parlent mal français.

Il ne s'agit pas de dénigrer le C, qui est un langage que j'utilise moi même souvent, mais simplement d'attirer l'attention aussi souvent que possible sur le fait que:

• oui, C++ hérite du C, et propose, de ce fait, toute la palette des possibilités issue du C mais
• non, il ne faut pas considérer C++ comme "du C avec des classes" ( C with classes)
• il est possible de trouver une possibilité propre à C++ qui sera généralement bien plus simple, sécurisante et facile à lire à l'ensemble pour quasi la totalité des possibilités issues du C

Mode binaire ou mode texte, ca dépend essentiellement de la façon dont les fichiers sont structurés, pas des données qu'ils contiennent ou de leur utilisation future (et encore moins de leur extension).

En mode texte, on s'attend à voir des lignes de longueur variables, séparées par des retours à la ligne, et parfois des séparateurs intermédiaires. On lit ligne à ligne (ou champ à champ) sans se préoccupper de la position où l'on se trouve, et on fait en général des getline, qui lisent jusqu'au prochain délimiteur. A chaque lecture, ces délimiteurs sont supprimés: l'utilisateur n'y a jamais accès.

Je connais bien la différence entre un fichier dit (d'ailleurs de manière erronnée) "binaire" (que l'on devrait plutôt qualifier de "fichier contenant des données brutes) et un fichier que l'on qualifie volontiers de "fichier texte"...

Je sais aussi que l'extension n'a a priori rien à voir avec le contenu réel du fichier.

Par contre, je te rappelle que le but de l'extension est, sommes toutes, de permettre à l'utilisateur, et dans une certaine mesure au système d'exploitation, de déterminer avec quelle application ouvrir le fichier...

Or, classiquement, un fichier portant l'extension *.txt sera ouvert avec... un éditeur de texte "simple" (bloc note sous windows, gedit, nano, emacs ou similaire sous linux) qui vont considérer chaque byte comme étant... des caractères exclusivement.

Et c'est là qu'apparait le problème de l'ouverture du fichier:

Si tu essaye de gérer le contenu d'un fichier de type dit "texte" en tant que données brutes, ou celui d'un fichier de type dit "binaire" en tant que caractères, tu t'expose à un tas de problème: tes entiers qui ne dépasseront jamais 9999 ou des bips et autres caractères cabalistiques (dans le meilleur des cas), selon le cas

En mode binaire, on doit spécifier, à chaque lecture, le nombre d'octets qu'on lit. Ceci est donc adapté à des fichiers où les champs ou les enregistrements sont de longueur fixe (mais qui peuvent parfaitement contenir des chaines de texte). Et on utilisera alors des read. Ces positions fixes permettront également plus facilement de se déplacer dans le fichier sans le lire avec des seekg par exemple.

Le choix entre mode texte et mode binaire ne dépend pas de la nature ou de l'utilisation qu'on va faire des données, mais seulement de la façon dont elles sont organisées dans le fichier. Un grand nombre de fichiers textes sont formattés "en ASCII colonné", et se lisent en mode binaire.

Je n'en disconvient pas, mais rien dans la question de Youry ne donne la moindre information nous permettant d'envisager seulement que ce fut le cas...

Dans le doute, il est donc important de lui permettre de donner des précisions sur le sujet, et, le fait de lui indiquer l'incohérence "ressentie" entre son code et ses explications est une possibilités (peut être pas la meilleure ) pour l'inciter à apporter des précisions

D'autres que moi, plus expérimentés, répondront sans doute de façon plus élaborée et argumentée. Cela dit, il me semble que tu fais complètement fausse route : si les outils du C sont disponibles en C++ c'est avant tout pour permettre une compatibilité avec du code antérieur existant et en aucune façon parce que cela serait recommandé ou souhaitable de les utiliser dans des programmes nouveaux lorsque ce n'est pas indispensable pour une raison bien précise.
Quant aux pointeurs et tableaux, ils constituent une des difficultés et sources d'erreur majeure du C et un des avantages du C++ c'est de permettre de les éviter dans un grand nombre de cas et de construire ainsi du code plus lisible, plus facile à maintenir et moins 'error-prone', ce qui est un des objectifs majeurs du C++

L'idée n'est pas de dire que ce n'est pas standard, mais de dire que si le but est de faire du C++, il y a des alternatives supérieures.

ptyxs et JolyLoic mis le doigt sur le but de mon intervention...

Il faut bien comprendre, fcharton, que nous sommes visiblement en présence de quelqu'un qui:

1. débute en C++
2. n'a qu'une connaissance parcellaire du C

( @ Youry : il ne faut pas te sentir agressé par cette phrase: nous sommes tous passés par là, et ce n'est une constatation finalement assez objective de la situation )

Or, s'il y a une seule série de pièges à c** dans lequel tous les programmeurs devront, s'ils doivent répondre honnêtement, avouer être tombés à un moment ou un autre en C, c'est, très clairement, ceux qui concernent la gestion de pointeurs, de l'allocation dynamique et de fuites mémoire.

Et je sais par expérience qu'il est d'autant plus difficile d'abandonner une (mauvaise) habitude qu'elle a été pratiquée longtemps

Dés lors, il est presque de notre devoir de donner les bonnes habitudes "aussi vite que possible", et ca passe par celle... de ne pas utiliser l'allocation dynamique de la mémoire si on peut l'éviter

[koala01]

Les lectures à base de FILE sont effectivement des héritages du C, mais tous les compilateurs C++ (que je connais) les reconnaissent, les acceptent, et les fournissent dans leurs bibliothèques standard. Si on va par là, c'est plus standard que Boost...

Quant à char*, quelle drôle d'idée!

Le fait est que, venant du C, on a vite fait d'assimiler un char* à... une chaine de caractères (comprend: de caractères "imprimables", composée d'un tableau de caractères terminé par '\0')

Je veux pour preuve de cette affirmation la toute récente discussion tableau d'element hexa tronqué qui n'est qu'une illustration supplémentaire (le problème se pose très régulièrement) de la confusion si facile à faire en C

FILE appartient au C++, tout comme "football" est un mot français d'origine anglaise. L'utiliser pour lire des fichiers, c'est sans doute pas très standard (comme on parle un français "non standard" dans plein de régions du monde), mais de là à "tirer un signal d'alarme"?

Ca me rappelle ces parisiens qui se moquent des marseillais, ou des québecois, parce qu'ils trouvent qu'ils parlent mal français.

Il ne s'agit pas de dénigrer le C, qui est un langage que j'utilise moi même souvent, mais simplement d'attirer l'attention aussi souvent que possible sur le fait que:

• oui, C++ hérite du C, et propose, de ce fait, toute la palette des possibilités issue du C mais
• non, il ne faut pas considérer C++ comme "du C avec des classes" ( C with classes)
• il est possible de trouver une possibilité propre à C++ qui sera généralement bien plus simple, sécurisante et facile à lire à l'ensemble pour quasi la totalité des possibilités issues du C

Mode binaire ou mode texte, ca dépend essentiellement de la façon dont les fichiers sont structurés, pas des données qu'ils contiennent ou de leur utilisation future (et encore moins de leur extension).

En mode texte, on s'attend à voir des lignes de longueur variables, séparées par des retours à la ligne, et parfois des séparateurs intermédiaires. On lit ligne à ligne (ou champ à champ) sans se préoccupper de la position où l'on se trouve, et on fait en général des getline, qui lisent jusqu'au prochain délimiteur. A chaque lecture, ces délimiteurs sont supprimés: l'utilisateur n'y a jamais accès.

Je connais bien la différence entre un fichier dit (d'ailleurs de manière erronnée) "binaire" (que l'on devrait plutôt qualifier de "fichier contenant des données brutes) et un fichier que l'on qualifie volontiers de "fichier texte"...

Je sais aussi que l'extension n'a a priori rien à voir avec le contenu réel du fichier.

Par contre, je te rappelle que le but de l'extension est, sommes toutes, de permettre à l'utilisateur, et dans une certaine mesure au système d'exploitation, de déterminer avec quelle application ouvrir le fichier...

Or, classiquement, un fichier portant l'extension *.txt sera ouvert avec... un éditeur de texte "simple" (bloc note sous windows, gedit, nano, emacs ou similaire sous linux) qui vont considérer chaque byte comme étant... des caractères exclusivement.

Et c'est là qu'apparait le problème de l'ouverture du fichier:

Si tu essaye de gérer le contenu d'un fichier de type dit "texte" en tant que données brutes, ou celui d'un fichier de type dit "binaire" en tant que caractères, tu t'expose à un tas de problème: tes entiers qui ne dépasseront jamais 9999 ou des bips et autres caractères cabalistiques (dans le meilleur des cas), selon le cas

En mode binaire, on doit spécifier, à chaque lecture, le nombre d'octets qu'on lit. Ceci est donc adapté à des fichiers où les champs ou les enregistrements sont de longueur fixe (mais qui peuvent parfaitement contenir des chaines de texte). Et on utilisera alors des read. Ces positions fixes permettront également plus facilement de se déplacer dans le fichier sans le lire avec des seekg par exemple.

Le choix entre mode texte et mode binaire ne dépend pas de la nature ou de l'utilisation qu'on va faire des données, mais seulement de la façon dont elles sont organisées dans le fichier. Un grand nombre de fichiers textes sont formattés "en ASCII colonné", et se lisent en mode binaire.

Je n'en disconvient pas, mais rien dans la question de Youry ne donne la moindre information nous permettant d'envisager seulement que ce fut le cas...

Dans le doute, il est donc important de lui permettre de donner des précisions sur le sujet, et, le fait de lui indiquer l'incohérence "ressentie" entre son code et ses explications est une possibilités (peut être pas la meilleure ) pour l'inciter à apporter des précisions

D'autres que moi, plus expérimentés, répondront sans doute de façon plus élaborée et argumentée. Cela dit, il me semble que tu fais complètement fausse route : si les outils du C sont disponibles en C++ c'est avant tout pour permettre une compatibilité avec du code antérieur existant et en aucune façon parce que cela serait recommandé ou souhaitable de les utiliser dans des programmes nouveaux lorsque ce n'est pas indispensable pour une raison bien précise.
Quant aux pointeurs et tableaux, ils constituent une des difficultés et sources d'erreur majeure du C et un des avantages du C++ c'est de permettre de les éviter dans un grand nombre de cas et de construire ainsi du code plus lisible, plus facile à maintenir et moins 'error-prone', ce qui est un des objectifs majeurs du C++

L'idée n'est pas de dire que ce n'est pas standard, mais de dire que si le but est de faire du C++, il y a des alternatives supérieures.

ptyxs et JolyLoic mis le doigt sur le but de mon intervention...

Il faut bien comprendre, fcharton, que nous sommes visiblement en présence de quelqu'un qui:

1. débute en C++
2. n'a qu'une connaissance parcellaire du C

( @ Youry : il ne faut pas te sentir agressé par cette phrase: nous sommes tous passés par là, et ce n'est une constatation finalement assez objective de la situation )

Or, s'il y a une seule série de pièges à c** dans lequel tous les programmeurs devront, s'ils doivent répondre honnêtement, avouer être tombés à un moment ou un autre en C, c'est, très clairement, ceux qui concernent la gestion de pointeurs, de l'allocation dynamique et de fuites mémoire.

Et je sais par expérience qu'il est d'autant plus difficile d'abandonner une (mauvaise) habitude qu'elle a été pratiquée longtemps

Dés lors, il est presque de notre devoir de donner les bonnes habitudes "aussi vite que possible", et ca passe par celle... de ne pas utiliser l'allocation dynamique de la mémoire si on peut l'éviter

[Invité]

Le fait est que, venant du C, on a vite fait d'assimiler un char* à... une chaine de caractères (comprend: de caractères "imprimables", composée d'un tableau de caractères terminé par '\0')

Même en C++ d'ailleurs... Le problème de fond, c'est que le nom de ce type natif entretient cette confusion entre 'variable signée d'un octet' et 'caractère'. Et c'est pas le développement de l'unicode qui va arranger les choses...

[*]non, il ne faut pas considérer C++ comme "du C avec des classes" ( C with classes)

Même si je partage cette opinion, je souris toujours quand je la lis... C With Classes n'était il pas justement le nom donné au C++ par son créateur? et C++, le nom suivant (et définitif) ne proclame-t-il pas cette filiation?

Je me demande souvent dans quelle mesure cette attitude relève de la 'foi des convertis'. Un certain nombre de professionnels qui pratiquent aujourd'hui le C++ viennent du C, et ne se sont ralliés au C++ qu'assez tard...

Or, classiquement, un fichier portant l'extension *.txt sera ouvert avec... un éditeur de texte "simple" (bloc note sous windows, gedit, nano, emacs ou similaire sous linux) qui vont considérer chaque byte comme étant... des caractères exclusivement.

Et c'est là qu'apparait le problème de l'ouverture du fichier:

Pas forcément, et c'était justement mon propos... Un ASCII délimité s'ouvrira sans difficulté sur un éditeur de texte, mais sa structure en fera, pour un programme qui devrait le lire, un excellent candidat à une lecture en "mode binaire".

Francois

[koala01]

Même en C++ d'ailleurs... Le problème de fond, c'est que le nom de ce type natif entretient cette confusion entre 'variable signée d'un octet' et 'caractère'. Et c'est pas le développement de l'unicode qui va arranger les choses...

Et c'est pour cela qu'il est important de faire la distinction dés que possible:

• std::string ou similaires pour ce qui est... chaines de caractères en tant que telles
• std::vector<char> (ou autre conteneur éventuellement mieux adapté le cas échéans) pour les données brutes

Parce qu'il n'y a rien à faire: une std::string et un std::vetor n'ont absolument pas les mêmes fonctions membres, leur but étant conceptuellement différent (mais les deux ont ceci en commun qu'elles évitent la pénible gestion dynamique de la mémoire)

Tu ne sera en effet pas tenté d'invoquer la fonction substr sur un std::vector, ni d'invoquer push_back sur une std::string

Même si je partage cette opinion, je souris toujours quand je la lis... C With Classes n'était il pas justement le nom donné au C++ par son créateur? et C++, le nom suivant (et définitif) ne proclame-t-il pas cette filiation?

C++ revendique clairement la filiation aussi...

De l'aveu même de stroutrup, ++ est la particule d'incréementation classique, et C++ signifie "du C avec quelque chose de plus"

Mais il faudrait beaucoup plus parler d'hérédité que de filiation

Le rapport qu'il peut y avoir à l'heure actuelle entre le C++ et le C tient en effet plus à la transmission hériditaire de chromosomes qu'à la transmission du nom de famille: certaines caractéristiques sont communes, mais personne n'accepte que l'on confonde le père et le fils

Je me demande souvent dans quelle mesure cette attitude relève de la 'foi des convertis'. Un certain nombre de professionnels qui pratiquent aujourd'hui le C++ viennent du C, et ne se sont ralliés au C++ qu'assez tard...

Pas de ma part, je peux te l'assurer...

Cependant, j'admets que beaucoup de profs / cours /tutos / livres basent leur approche sur le fait que ce C++ hérite du C et placent la connaissance du C comme un pré-requis indispensable...

Or, je peux t'assurer qu'il est possible d'apprendre le C++ sans même avoir jamais écrit ne serait-ce qu'une ligne de code en C...

J'ai d'ailleurs réussi à convaincre un prof qu'il devrait presque commencer son cours de C++ par

Vous avez appris le C, et vous l'avez compris...
C'est très bien...
Pour apprendre le C++, vous commencez par tout oublier

Pas forcément, et c'était justement mon propos... Un ASCII délimité s'ouvrira sans difficulté sur un éditeur de texte, mais sa structure en fera, pour un programme qui devrait le lire, un excellent candidat à une lecture en "mode binaire".

Francois

A ceci près qu'il reste un point que tu passe sous silence:

La lecture d'un fichier n'a souvent que peu de sens si ce n'est pas pour récupérer les informations qu'il contient en vue d'un traitement quelconque

Un fichier ASCII délimité est donc un candidat idéal à l'ouverture et à la lecture en "mode binaire", mais nécessitera derrière tout un processus de conversion des informations "numériques" en types adéquats...

Que ce soit en C (avec FILE fscanf et consort) ou en C++ (avec ifstream, getline et >> ), je ne suis pas sur que le fait de séparer les deux processus permette de gagner énormément de temps par rapport à une lecture séquentielle "classique" (comprend: convertissant les informations au fur et à mesure de la lecture)

[Alp]

Même si je partage cette opinion, je souris toujours quand je la lis... C With Classes n'était il pas justement le nom donné au C++ par son créateur? et C++, le nom suivant (et définitif) ne proclame-t-il pas cette filiation?

Oui, au tout début des années 80, quand le C++ n'était justement que du C avec des classes...

Puis il y a eu bien de choses en plus : exceptions, templates, la SL et la STL, j'en passe et des meilleures. En gros, la standardisation en 1998 du langage C++ par un commité ISO a définitivement mis fin à cette vue du C++.

Aujourd'hui, le C++, c'est le "C++ Moderne" tel qu'on essaye de l'expliquer/enseigner sur le forum C++ de Developpez, où l'on ne voit des pointeurs que quand on est obligé, on utilise le RAII, on utilise à bon escient l'orienté objet, etc...

[Invité]

En fait, j'ai l'impression qu'il y a eu au moins trois étapes...

1- à la fin des années 80, et au début des années 90, une utilisation du C++ comme un C étendu : fonctions membres qui étendent les structs, gestion de la mémoire simplifée (avec les new typés au lieu des mallocs sur void), iostream qui remplacent les printf(), déclarations de variables où l'on veut, exceptions, et l'habitude d'utiliser davantage le compilateur pour détecter les erreurs dans le code.
2- pendant le gros des années 90, la POO comme unique doctrine, avec les hierarchies de classes de plus en plus complexes, un accent mis sur l'héritage et le polymorphisme, les surcharges, etc...
3- depuis une dizaine d'année, une vision du C++ comme langage "presque de haut niveau", avec des bibliothèques de plus en plus complètes, et la programmation générique qui remplace la POO comme paradigme central.

A mon avis, si le C++ survit encore quelques décennies (je n'en suis pas certain, car il me semble que la tendance actuelle consistant à vouloir en faire un langage de haut niveau pourrait bien le rendre obsolete à assez court terme, un peu comme le pascal objet a tué le pascal...), on verra apparaitre de nouveaux paradigmes, que la génération suivante de programmeurs définira comme le "vrai C++". Les programmeurs Fortran et Cobol (autres vieux langages) racontent des histoires similaires sur l'évolution des bonnes pratiques.

Mais il y a dans tout cela une grosse part de mode. Pour répondre à Koala01, je pense que si dans les années 90, on avait effectivement tendance à présenter le C++ comme un raffinement du C, le dogme actuel, qui fait du C++ quelque chose de "complètement différent" n'est pas plus tenable.

Et j'avoue sourire en voyant arriver de jeunes programmeurs qui ont un peu peur des pointeurs, qui se signent avant d'écrire un cast (et sont probablement persuadés que reinterpret_cast<> est une invention du diable), ou qui, quand on leur pose un problème, n'importe lequel, froncent les sourcils et disent : on ne pourrait pas utiliser boost? Ca me fait un peu penser à ces autres spécialistes qui, quel que soit la question posée, répondent "BDD relationelle + SQL".

Je pense que le C++ est un langage très riche, permettant des approches variées (d'un langage procédural à la C à de la POO assez pure, à des choses plus fonctionnelles ou génériques), et que sa longévité s'explique partiellement par cette richesse, qui lui permet de survivre aux modes (là où des langages plus objet, plus procéduraux, plus génériques passent). Et je soupçonne que si l'on regardait les programmes C++ écrits aujourd'hui, on retrouverait cette variété de styles et de dialectes. Je ne crois pas que ce soit une mauvaise chose.

Maintenant, je reste d'accord avec la nécessité de parler un C++ 'mainstream', cela évite de longues discussions, et ca permet d'intégrer dans des équipes des programmeurs de générations et d'origines différentes. J'ai juste du mal avec ces "pratiques modernes' qui me paraissent toujours relever de ce que Brooks appelle les "silver bullets".

Francois

[koala01]

J'ai l'impression que l'on ne se comprend pas, du moins, dans les intentions que tu me prêtes...

Je reconnais parfaitement l'héritage du C que peut avoir le C++...

Mais, à l'heure actuelle, lorsque l'on voit tout ce qui fait partie du C++ et qui ne fait pas partie du C, on ne peut vraiment plus considérer le langage comme "du C avec un petit plus"(même s'il y a deux petits plus )...

Or, je suis partisan, comme en témoigne ma signature, de la doctrine qui veut que la solution la plus simple soit la meilleure

Cela implique peut être de définir "la solution la plus simple"

Pour moi, la "solution la plus simple" en programmation est la solution

• qui ne me fait pas passer par Moscou pour relier Paris à Lyon
• qui m'évite au maximum les problèmes
• qui me permet, en cas de problème, de le retrouver "facilement"
• qui me permet, en cas de problème, de le résoudre "facilement"
• qui rendra la relecture et la compréhension la plus simple possible
• accessoirement qui me fera en faire le moins possible

Il faut avouer que, de ce point de vue, les possibilités propres au C++ ont un réel avantage sur celles issues du C

Je ne suis, en toute honnêteté, pas partisan ni de l'utilisation de boost, ni de la généricité à tout prix...

Mais, si ma solution " de simplicité " passe par l'un ou l'autre, surtout dans le cadre du dernier point exposé, je n'hésiterai pas une seconde à les utiliser

Par contre, je ne trouve aucune raison suffisante pour envisager l'utilisation des possibilités issues du C

[ptyxs]

Pour moi, la "solution la plus simple" en programmation est la solution

• qui ne me fait pas passer par Moscou pour relier Paris à Lyon
• qui m'évite au maximum les problèmes
• qui me permet, en cas de problème, de le retrouver "facilement"
• qui me permet, en cas de problème, de le résoudre "facilement"
• qui rendra la relecture et la compréhension la plus simple possible
• accessoirement qui me fera en faire le moins possible

Il faut avouer que, de ce point de vue, les possibilités propres au C++ ont un réel avantage sur celles issues du C

Pour aller dans le même sens, on pourrait sans doute ajouter aussi :

• qui rendra mon code plus aisé à lire, à comprendre et donc à maintenir, à faire évoluer, à déboguer pour d'autres qui viendraient après moi ou avec qui je collabore...

[Invité]

Pour aller dans le même sens, on pourrait sans doute ajouter aussi :

• qui rendra mon code plus aisé à lire, à comprendre et donc à maintenir, à faire évoluer, à déboguer pour d'autres qui viendraient après moi ou avec qui je collabore...

Il est difficile de n'être pas d'accord.

Mais là, j'ai l'impression qu'il s'agit plus d'un pb de management, ou de ressources humaines que de langage. Les codes les plus faciles à lire sont généralement écrits par des gens qui "pensent comme toi", soit qu'ils aient les mêmes origines, le même bagage, soit qu'ils aient lu les mêmes livres.

Si tu travailles avec des gens qui viennent du C, et qui ont appris le C++ sur le tas, il y a de grosses chances qu'un code C avec de petits bouts de C++ dedans (une forme de C++ hérétique, je veux bien l'admettre, mais du C++ malgré tout) soit plus lisible et donc maintenable par le plus grand nombre.

Si tu travailles avec des gens un peu plus jeunes, qui ont été éduqués dans les normes POO les plus strictes, il y a des chances que l'équipe ait bâti une super hiérarchie de classes maison, et ton programme sera d'autant plus lisible qu'il suivra cette hiérarchie (aussi mal gaulée et peu évolutive soit elle).

Si tu travailles avec des gens formés (ou reformés) plus récemment, un code utilisant autant que possible la STL, ses algorithmes et éventuellement Boost, passera pour "plus lisible".

A ce stade, il faudrait aussi ajouter les librairies 'communes': un code horriblement compliqué écrit avec la librairie graphique obsolète mais que tout le monde connait est plus lisible et plus maintenable que le meilleur code écrit dans une librairie que seul son auteur utilise...

A mon avis, le seul moyen, dans une équipe, pour avoir du code lisible et maintenable par d'autre, c'est de s'arranger pour que
1- tous les membres de l'équipe aient les mêmes origines, ou aient lu les mêmes livres
2- tous les membres s'accordent à parler un idiome assez limité du C++ (d'autant plus limité que l'équipe est grande)
3- l'équipe soit très petite (deux ou trois), si elle est plus grande, un des membres doit avoir le dernier mot sur tous les problèmes de "style".
4- dans le cas d'une programme assez gros, une personne est chargée, périodiquement, de "remettre au propre" le code du programme (éventuellement le sien), de façon à conserver l'unité stylistique du programme (ses décisions sont bien sur sans appel...)

Ce n'est pas vraiment lié, à mon avis, à la nature du C++ utilisé.

Francois

[koala01]

Pour aller dans le même sens, on pourrait sans doute ajouter aussi :

• qui rendra mon code plus aisé à lire, à comprendre et donc à maintenir, à faire évoluer, à déboguer pour d'autres qui viendraient après moi ou avec qui je collabore...

<snip>

Aussi, mais, là, nous entrons dans un autre débat

Ce sur quoi je voulais surtout insister, c'est sur le fait que C++ fournit tout ce qu'il faut pour rendre le travail plus simple et plus "sécurisant" (comprenez: de nature à éviter un maximum de bugs pour lesquels le risque est important si l'on utilise les possibilités issues du C)

De ce seul fait, il est cohérent d'estimer que la solution la meilleure passera d'office par l'utilisation adéquate des possibilités propres au C++ de préférence à toute autre issue du C.

Et ce forum est le lieu idéal pour permettre au plus grand nombre de prendre les habitudes qui leur faciliteront la vie.

C'est la raison pour laquelle vous remarquerez souvent que certains participants (dont je fais partie) plaideront de manière systématique pour l'utilisation des possibilités issues du C++.

Et c'est aussi la raison pour laquelle ceux qui se basent sur "ce qui se faisait au siècle dernier" et refusent d'admettre que les choses ont bien changé depuis (et changeront d'ailleurs peut être encore) rendent en définitive un très mauvais service aux gens qui viennent poser leur question

[Arzar]

Pour moi, la "solution la plus simple" en programmation est la solution

* qui ne me fait pas passer par Moscou pour relier Paris à Lyon
* qui m'évite au maximum les problèmes
* qui me permet, en cas de problème, de le retrouver "facilement"
* qui me permet, en cas de problème, de le résoudre "facilement"
* qui rendra la relecture et la compréhension la plus simple possible
* accessoirement qui me fera en faire le moins possible

Hmm, c'est un bien bel objectif, mais j'ai peur que la librairie iostream soit loin d'être un tel parangon...

Au fond la question de l'OP est : Comment lire l'intégralité d'un fichier texte dans un buffer ?
La réponse de la faq convient très bien pour la lecture de fichier texte formatée. Mais si l'on veut juste charger un fichier brut dans un vector de char ? Quel est la "solution la plus simple" ? Peut être avec des filebuf ?

Edit : D'ailleurs, même avec les ifstream en mode formaté, y a t'il un moyen simple d'éviter de passer par un stringstream intermédiaire et de charger directement dans un vector de char ?

[Invité]

Edit : D'ailleurs, même avec les ifstream en mode formaté, y a t'il un moyen simple d'éviter de passer par un stringstream intermédiaire et de charger directement dans un vector de char ?

Ce n'est pas à cela que servent les istream_iterators ? Quelque chose du genre

Code :

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

1
2
3
4
 
vector<int> v;
ifstream fdat("data.txt");
copy(istream_iterator<int>(fdat),istream_iterator<int>(),back_inserter(v));

Ca marche avec des données séparées par des blancs (espaces, tabs, retour chariot, etc...), mais je serait étonné qu'on ne puisse pas l'adapter à des fichiers et des structures plus complexes...

Et pour l'écriture, tu as des choses commes

Code :

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

1
2
3
 
ofstream fdat("res.txt");
copy(v.begin(),v.end(), ostream_iterator<int>(fdat,";"));

Là les données de ton vecteur sont séparées par des point virgules, façon fichier csv...

EDIT : 'scuse, j'avais pas vu "vecteur de char", là, il y a une ruse : il faut empêcher la librairie de sauter les espaces, en enlevant le flag ios::skipws de ton stream... Pour cela tu utilises le manipulateur noskipws...
Et là, un unique

Code :

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

copy(istream_iterator<char>(fdat),istream_iterator<char>(),back_inserter(v));

EDIT (bis) : pour des données binaires, il vaut mieux utiliser des vector<unsigned char> que des vector<char>. Sur de nombreux systèmes, les char sont signés, et cela provoque toutes sortes d'effets de bords, quand un élément d'un vector<char> est malencontreusement converti en int, par exemple...

J'ai bon, là?
Francois, fossile...

[koala01]

Hmm, c'est un bien bel objectif, mais j'ai peur que la librairie iostream soit loin d'être un tel parangon...

Et pourtant...

Le simple fait que les classes *fstream applique le RAII et la libération des ressources à la destruction est déjà fortement de nature à simplifier les choses...

Lorsque tu ouvre un flux sur un fichier, tu sais que, quoi qu'il arrive, il sera fermé lorsque tu quittera la portée dans laquelle il est déclaré

Rien que cela plaide déjà en faveur de l'utilisation des i/o fstream par rapport à celle de FILE

Au fond la question de l'OP est : Comment lire l'intégralité d'un fichier texte dans un buffer ?
La réponse de la faq convient très bien pour la lecture de fichier texte formatée. Mais si l'on veut juste charger un fichier brut dans un vector de char ? Quel est la "solution la plus simple" ? Peut être avec des filebuf ?

De la même manière, l'utilisation systématique d'un std::vecto<char>, même si elle te demande de passer par la fonction resize() pour être sur d'éviter les innombrables réallocations internes que pourrait nécessiter une lecture "byte à byte" du fichier est bel et bien "la solution la plus simple" comparée à la gestion manuelle de la mémoire que peut nécessiter un simple char*

Edit : D'ailleurs, même avec les ifstream en mode formaté, y a t'il un moyen simple d'éviter de passer par un stringstream intermédiaire et de charger directement dans un vector de char ?

Il y a effectivement moyen... mais ne passant par un fichier binaire (comme je l'ai déjà dit, il ne faut pas ouvrir un fichier contenant des données brutes en mode "texte" )

(ceci dit, il y a moyen de le faire en ouvrant un fichier de type "texte" en mode texte, mais nous courrons le risque de rencontrer certains problèmes au niveau de la représentation des caractères de fin de ligne, si le fichier a été créé sur un système différent (créé sous linux et lu sous windows, ou inversement)

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
void foo()
{
    // nous avons besoin d'un tableau pour récupérer les données
    vector<char> toread;
    // et du flux de fichier, ouvert en mode "binaire" (le mal nommé)
    ifstream ifs("fichier.dat",ios_base::binary);
    // sauvegarder la position courante dans le fichier
    long pos=ifs.tellg();
    // se placer en fin de fichier
    ifs.seekg( 0 , std::ios_base::end );
    // récupérer la nouvelle position = la taille du fichier
    long size = ifs.tellg() ;
    // restaurer la position initiale du fichier
    ifs.seekg( pos,  std::ios_base::beg ) ;
    /* NOTA: tout ce que l'on a fait jusqu'ici aurait de toutes manières
     * du être fait en C aussi  ;)
     */
    /* redimentionons le tableau en une seule fois à la taille ad-hoc */
    toread.resize(size);
    /* Et lisons "d'une seule traite" l'ensemble du fichier */
    ifs.read(&toread[0],size);
}

[Arzar]

Aaaah oui, c'est vrai, il y a aussi la fonction read. C'est donc ça que voulait dire la faq par :

"La taille du buffer peut être différente de celle du fichier si le fichier n'a pas été ouvert en mode texte (en utilisant le mode std::ios_base::binary). Il est aussi possible d'utiliser la fonction read de std::ifstream en ayant au préalable alloué un buffer suffisamment grand. Pour connaître la taille à allouer, consulter la question Comment calculer la taille d'un fichier. "

Ok, a posterio c'est logique.
Peut-être pourrait-on modifier un peu la faq pour la rendre un peu plus explicite ? Je propose de rajouter un item "Comment effectuer une lecture binaire de l'intégralité d'un fichier dans un buffer ?" après le dernier item Comment effectuer des lectures / écritures binaires dans un fichier ?

Comment effectuer une lecture binaire de l'intégralité d'un fichier dans un buffer ?

Pour charger l'intégralité d'un fichier dans un buffer par une lecture binaire, il faut ouvrir le fichier avec le mode std::ios_base::binary et utiliser la fonction read de std::ifstream. Le buffer doit au préalable avoir été alloué de manière à possèder une taille suffisante.

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
#include <fstream>
#include <iostream>
 
int main()
{
    // on ouvre le fichier en lecture
    std::ifstream fichier( "fichier.txt", ios_base::binary );
 
    // ce vecteur nous servira de buffer
    vector<char> buffer;
 
    if ( fichier ) // ce test échoue si le fichier n'est pas ouvert
    {
       // calcul de la taille du fichier 
       //(voir FAQ : Comment calculer la taille d'un fichier ?)
       long pos = Fichier.tellg();
       fichier.seekg( 0 , std::ios_base::end );
       long size = Fichier.tellg() ;
       fichier.seekg( pos,  std::ios_base::beg ) ;
 
      // redimensionne le vecteur à la taille du fichier 
      buffer.resize(size);
      // et lit l'intégralité du fichier
      fichier.read(&buffer[0], size);
    }
}

[Antoine_935]

Cela signifie que dés que l'on remarque FILE, fread, fwrite, fopen, fclose ou même char* (plus toutes les choses auxquelles je ne pense pas), il faut tirer un signal d'alarme et bien faire comprendre à la personne qu'il travaille en C.

Je ne suis pas tout à fait d'accord.
Est-il formellement interdit de se servir d'autre chose que de la stl en c++ ?
Quand je dois faire des concaténations de nombreux strings je ne me sers pas de la classe mais bien d'un char*, c'est à la fois plus simple et plus rapide. Mais peut-être que j'ai raté une méthode utile.

Cela dit, je suis entièrement convaincu de l'intérêt de la stl sur les machines habituelles. Elle est par contre un peu trop lourde à mon goût pour le développement embarqué. On pourrait me répondre que je peux bien faire du C alors, mais l'orienté objet a de la valeur à mes yeux. Il en va ainsi pour beaucoup de choses qu'apporte le c++, même sans la stl.

[koala01]

Je ne suis pas tout à fait d'accord.
Est-il formellement interdit de se servir d'autre chose que de la stl en c++ ?

Bien sur que non, ce n'est pas interdit...

Mais c'est très fortement déconseillé

Quand je dois faire des concaténations de nombreux strings je ne me sers pas de la classe mais bien d'un char*, c'est à la fois plus simple et plus rapide.

Crois tu vraiment que le fait de devoir vérifier s'il te reste suffisemment de place pour effectuer la concaténation et devoir réallouer de la mémoire le cas échéans soit facile

Mais peut-être que j'ai raté une méthode utile.

Peut être simplement les opérateurs + et += redéfinis pour la classe string, qui fonctionnent aussi très bien avec des char*

Cela dit, je suis entièrement convaincu de l'intérêt de la stl sur les machines habituelles. Elle est par contre un peu trop lourde à mon goût pour le développement embarqué. On pourrait me répondre que je peux bien faire du C alors, mais l'orienté objet a de la valeur à mes yeux. Il en va ainsi pour beaucoup de choses qu'apporte le c++, même sans la stl.

Fais déjà attention à la différence (effectivement subtile) qui existe entre la SL (qui contient entre autre la classe string) et la STL qui manipule les modèle

Je n'ai, à mon grand dam, encore jamais eu l'occasion de travailler dans l'embarqué, mais, en théorie, l'utilisation des modèles ne devrait pas vraiment avoir d'impact particulier par rapport à une structure identique "classsique" étant donné que tout est fait au moment de la compilation...

La bonne question étant de savoir si, effectivement, la structure même des collections de la STL sont intéressante en embarqué... et, sur ce point, je ne suis pas en mesure de faire ma propre idée

[Arzar]

Quand je dois faire des concaténations de nombreux strings je ne me sers pas de la classe mais bien d'un char*, c'est à la fois plus simple et plus rapide. Mais peut-être que j'ai raté une méthode utile.

Et bien, on peut toujours essayer de comparer.
(Le sujet de départ a été bien traité, on peut se permettre un peu de hors-sujet )
Pour ma part, je pense que la solution C sera plus rapide, mais pas extrêmement plus rapide...

Pourrais-tu fournir un exemple de concaténations de nombreuses strings en C avec des char* ? Je prendrais alors ce code comme référence pour comparer à une solution C++.