sorry, mais le code que j'ai fourni est du C++, ça n'est certes pas
du C++ typique (tableau de char, open() & compagnie)
C'est même du C++ typique. Parfois, évidemment, c'est typique parce
qu'on ne sait pas autrement. Mais d'autres fois, parce qu'il y a des
contraints externes qui l'imposent. Ne t'en fais pas ; il m'arrive
d'écrire des choses pareilles aussi.
D'abord, autant que je sache, il n'a pas de problème avec des tableaux
de char. C'est possible (voire probable) qu'il pourrait faire ce qu'il
veut avec vector. En revanche, je suppose que ce qu'il a posté n'est pas
son application complète, et c'est tout à fait possible qu'il y a des
choses ailleurs qui fait que std::vector ne convient pas.
Les tableaux de 'char' (et d'autres types) sont des fonctionnalités de
bas niveau que tu ne devrais pas utiliser (elles sont utilisées, entre
autres, par la bibliothèque standard (STL) pour proposer des objets de
plus haut niveau comme std::string, std::vector, etc...).
Sauf que le code qu'il a posté *est* manifestement de ce bas niveau.
[...]
Un des grands avantages de C++, c'est qu'il permet l'accès à ce niveau
quand on en a besoin.
Maintenant, si tu tiens absolument à programmer comme on le ferait en
C, je te suggère le groupe news:fr.comp.lang.c ...
Parce que son code ne te plaît pas, il doit aller ailleurs. Depuis quand
c'est toi qui définis les règles du groupe ?
Moi, j'avoue que je commence à avoir un peu marre des gens qui envoie
les autres ailleurs dès que le code ne ressemble pas à ce qu'eux ils
font en C++. Il y a des cas évident où la question est hors sujet
(comment afficher un bouton avec Windows), mais il y en a de plus en
plus où le poster est envoyé ailleurs alors que son problème est du C++,
ou est peut-être du C++.
#include <string>
#include <fstream>
#include <iostream>
#include <string>
Deux fois <string>, mais ni <istream> ni <ostream>. Sans <istream> ni
<ostream>, ce n'est pas du C++ standard.
int main()
{
const std::string filename = "/chemin/fichier";
// Ouverture du fichier
std::ifstream inFile(filename.c_str());
Tu pourrais expliqué pourquoi le passage par std::string ?
Et évidemment, la sémantique de ifstream::open n'est pas celui du open
de Posix. Je suppose que s'il passe par l'open de bas niveau (plutôt que
d'utiliser des fstream ou des FILE*), c'est qu'il a besoin des
fonctionnalités qui s'y trouvent, mais qui ne se trouvent pas dans les
flux classiques. (Dans mes applications, je suis obligé à travailler à
ce niveau pour prèsque tout sauf les fichiers de log.)if (!inFile)
{
// Traitement de l'erreur d'ouverture...
}
else
{
// Lecture du contenu
std::string data;
std::copy(std::istreambuf_iterator<std::string::value_type>(inFile),
std::istreambuf_iterator<std::string::value_type>(),
std::back_inserter(data));
Ce qui ne fait pas du tout ce qu'il a fait. Il n'a lu qu'un nombre
défini des caractères au début du fichier, non tout le fichier.
Et franchement, écrire std::string::value_type à la place de char, c'est
de la masturbation mentale, ou de la complexité pour obfusquée.
for ( ; (i = data.find(find, i)) != std::string::npos ; )
Juste curieux, mais pourquoi « for » et non « while » ici ?
{
data.replace(i, find.length(), replace);
i += replace.length();
}
Son problème se situait à un niveau beaucoup plus bas. Et j'aimerais
bien voir la performance de ta solution avec un fichier qui consiste en
une million de ''.
En général, sa solution est préférable à la tienne. Mais dans
l'ensemble, je n'essaierais pas une transformation en place.
// Ouverture du fichier en écriture
std::ofstream outFile(filename.c_str());
if (!outFile)
{
// Traitement de l'erreur d'ouverture...
Tu ésquisses le seul aspect intéressant. Qu'est-ce que tu fais si
l'ouverture échoue ici ?
En fait, mon commentaire sur les transformations « en place » vaut
double ici ; j'écrirais les données en sortie dans un fichier
temporaire, et seulement lors que tout c'est bien passé, je supprimerais
le fichier initial, et je rénommerais le fichier temporaire.
Et la gestion des erreurs ?
[...]
Et le return ? Tu ne veux sûrement pas renvoyer 0 s'il y a eu une
erreur.
Dans l'ensemble, son essai me semblait aussi bon, sinon mieux que le
tien.
sorry, mais le code que j'ai fourni est du C++, ça n'est certes pas
du C++ typique (tableau de char, open() & compagnie)
C'est même du C++ typique. Parfois, évidemment, c'est typique parce
qu'on ne sait pas autrement. Mais d'autres fois, parce qu'il y a des
contraints externes qui l'imposent. Ne t'en fais pas ; il m'arrive
d'écrire des choses pareilles aussi.
D'abord, autant que je sache, il n'a pas de problème avec des tableaux
de char. C'est possible (voire probable) qu'il pourrait faire ce qu'il
veut avec vector. En revanche, je suppose que ce qu'il a posté n'est pas
son application complète, et c'est tout à fait possible qu'il y a des
choses ailleurs qui fait que std::vector ne convient pas.
Les tableaux de 'char' (et d'autres types) sont des fonctionnalités de
bas niveau que tu ne devrais pas utiliser (elles sont utilisées, entre
autres, par la bibliothèque standard (STL) pour proposer des objets de
plus haut niveau comme std::string, std::vector, etc...).
Sauf que le code qu'il a posté *est* manifestement de ce bas niveau.
[...]
Un des grands avantages de C++, c'est qu'il permet l'accès à ce niveau
quand on en a besoin.
Maintenant, si tu tiens absolument à programmer comme on le ferait en
C, je te suggère le groupe news:fr.comp.lang.c ...
Parce que son code ne te plaît pas, il doit aller ailleurs. Depuis quand
c'est toi qui définis les règles du groupe ?
Moi, j'avoue que je commence à avoir un peu marre des gens qui envoie
les autres ailleurs dès que le code ne ressemble pas à ce qu'eux ils
font en C++. Il y a des cas évident où la question est hors sujet
(comment afficher un bouton avec Windows), mais il y en a de plus en
plus où le poster est envoyé ailleurs alors que son problème est du C++,
ou est peut-être du C++.
#include <string>
#include <fstream>
#include <iostream>
#include <string>
Deux fois <string>, mais ni <istream> ni <ostream>. Sans <istream> ni
<ostream>, ce n'est pas du C++ standard.
int main()
{
const std::string filename = "/chemin/fichier";
// Ouverture du fichier
std::ifstream inFile(filename.c_str());
Tu pourrais expliqué pourquoi le passage par std::string ?
Et évidemment, la sémantique de ifstream::open n'est pas celui du open
de Posix. Je suppose que s'il passe par l'open de bas niveau (plutôt que
d'utiliser des fstream ou des FILE*), c'est qu'il a besoin des
fonctionnalités qui s'y trouvent, mais qui ne se trouvent pas dans les
flux classiques. (Dans mes applications, je suis obligé à travailler à
ce niveau pour prèsque tout sauf les fichiers de log.)
if (!inFile)
{
// Traitement de l'erreur d'ouverture...
}
else
{
// Lecture du contenu
std::string data;
std::copy(std::istreambuf_iterator<std::string::value_type>(inFile),
std::istreambuf_iterator<std::string::value_type>(),
std::back_inserter(data));
Ce qui ne fait pas du tout ce qu'il a fait. Il n'a lu qu'un nombre
défini des caractères au début du fichier, non tout le fichier.
Et franchement, écrire std::string::value_type à la place de char, c'est
de la masturbation mentale, ou de la complexité pour obfusquée.
for ( ; (i = data.find(find, i)) != std::string::npos ; )
Juste curieux, mais pourquoi « for » et non « while » ici ?
{
data.replace(i, find.length(), replace);
i += replace.length();
}
Son problème se situait à un niveau beaucoup plus bas. Et j'aimerais
bien voir la performance de ta solution avec un fichier qui consiste en
une million de '\'.
En général, sa solution est préférable à la tienne. Mais dans
l'ensemble, je n'essaierais pas une transformation en place.
// Ouverture du fichier en écriture
std::ofstream outFile(filename.c_str());
if (!outFile)
{
// Traitement de l'erreur d'ouverture...
Tu ésquisses le seul aspect intéressant. Qu'est-ce que tu fais si
l'ouverture échoue ici ?
En fait, mon commentaire sur les transformations « en place » vaut
double ici ; j'écrirais les données en sortie dans un fichier
temporaire, et seulement lors que tout c'est bien passé, je supprimerais
le fichier initial, et je rénommerais le fichier temporaire.
Et la gestion des erreurs ?
[...]
Et le return ? Tu ne veux sûrement pas renvoyer 0 s'il y a eu une
erreur.
Dans l'ensemble, son essai me semblait aussi bon, sinon mieux que le
tien.
sorry, mais le code que j'ai fourni est du C++, ça n'est certes pas
du C++ typique (tableau de char, open() & compagnie)
C'est même du C++ typique. Parfois, évidemment, c'est typique parce
qu'on ne sait pas autrement. Mais d'autres fois, parce qu'il y a des
contraints externes qui l'imposent. Ne t'en fais pas ; il m'arrive
d'écrire des choses pareilles aussi.
D'abord, autant que je sache, il n'a pas de problème avec des tableaux
de char. C'est possible (voire probable) qu'il pourrait faire ce qu'il
veut avec vector. En revanche, je suppose que ce qu'il a posté n'est pas
son application complète, et c'est tout à fait possible qu'il y a des
choses ailleurs qui fait que std::vector ne convient pas.
Les tableaux de 'char' (et d'autres types) sont des fonctionnalités de
bas niveau que tu ne devrais pas utiliser (elles sont utilisées, entre
autres, par la bibliothèque standard (STL) pour proposer des objets de
plus haut niveau comme std::string, std::vector, etc...).
Sauf que le code qu'il a posté *est* manifestement de ce bas niveau.
[...]
Un des grands avantages de C++, c'est qu'il permet l'accès à ce niveau
quand on en a besoin.
Maintenant, si tu tiens absolument à programmer comme on le ferait en
C, je te suggère le groupe news:fr.comp.lang.c ...
Parce que son code ne te plaît pas, il doit aller ailleurs. Depuis quand
c'est toi qui définis les règles du groupe ?
Moi, j'avoue que je commence à avoir un peu marre des gens qui envoie
les autres ailleurs dès que le code ne ressemble pas à ce qu'eux ils
font en C++. Il y a des cas évident où la question est hors sujet
(comment afficher un bouton avec Windows), mais il y en a de plus en
plus où le poster est envoyé ailleurs alors que son problème est du C++,
ou est peut-être du C++.
#include <string>
#include <fstream>
#include <iostream>
#include <string>
Deux fois <string>, mais ni <istream> ni <ostream>. Sans <istream> ni
<ostream>, ce n'est pas du C++ standard.
int main()
{
const std::string filename = "/chemin/fichier";
// Ouverture du fichier
std::ifstream inFile(filename.c_str());
Tu pourrais expliqué pourquoi le passage par std::string ?
Et évidemment, la sémantique de ifstream::open n'est pas celui du open
de Posix. Je suppose que s'il passe par l'open de bas niveau (plutôt que
d'utiliser des fstream ou des FILE*), c'est qu'il a besoin des
fonctionnalités qui s'y trouvent, mais qui ne se trouvent pas dans les
flux classiques. (Dans mes applications, je suis obligé à travailler à
ce niveau pour prèsque tout sauf les fichiers de log.)if (!inFile)
{
// Traitement de l'erreur d'ouverture...
}
else
{
// Lecture du contenu
std::string data;
std::copy(std::istreambuf_iterator<std::string::value_type>(inFile),
std::istreambuf_iterator<std::string::value_type>(),
std::back_inserter(data));
Ce qui ne fait pas du tout ce qu'il a fait. Il n'a lu qu'un nombre
défini des caractères au début du fichier, non tout le fichier.
Et franchement, écrire std::string::value_type à la place de char, c'est
de la masturbation mentale, ou de la complexité pour obfusquée.
for ( ; (i = data.find(find, i)) != std::string::npos ; )
Juste curieux, mais pourquoi « for » et non « while » ici ?
{
data.replace(i, find.length(), replace);
i += replace.length();
}
Son problème se situait à un niveau beaucoup plus bas. Et j'aimerais
bien voir la performance de ta solution avec un fichier qui consiste en
une million de ''.
En général, sa solution est préférable à la tienne. Mais dans
l'ensemble, je n'essaierais pas une transformation en place.
// Ouverture du fichier en écriture
std::ofstream outFile(filename.c_str());
if (!outFile)
{
// Traitement de l'erreur d'ouverture...
Tu ésquisses le seul aspect intéressant. Qu'est-ce que tu fais si
l'ouverture échoue ici ?
En fait, mon commentaire sur les transformations « en place » vaut
double ici ; j'écrirais les données en sortie dans un fichier
temporaire, et seulement lors que tout c'est bien passé, je supprimerais
le fichier initial, et je rénommerais le fichier temporaire.
Et la gestion des erreurs ?
[...]
Et le return ? Tu ne veux sûrement pas renvoyer 0 s'il y a eu une
erreur.
Dans l'ensemble, son essai me semblait aussi bon, sinon mieux que le
tien.
[*] Ce qui est amusant, c'est qu'il y a déjà eu des personnes ici-même qui
se sont vues redirigées sur news:fr.comp.os.unix ou fcomp pour moins que ça.
[*] Ce qui est amusant, c'est qu'il y a déjà eu des personnes ici-même qui
se sont vues redirigées sur news:fr.comp.os.unix ou fcomp pour moins que ça.
[*] Ce qui est amusant, c'est qu'il y a déjà eu des personnes ici-même qui
se sont vues redirigées sur news:fr.comp.os.unix ou fcomp pour moins que ça.
Et aussi a cross-poster plutot que multiposter (ou mieux encore pour
cet exemple, te contenter de fr.comp.os.unix).
A+
Et aussi a cross-poster plutot que multiposter (ou mieux encore pour
cet exemple, te contenter de fr.comp.os.unix).
A+
Et aussi a cross-poster plutot que multiposter (ou mieux encore pour
cet exemple, te contenter de fr.comp.os.unix).
A+
sorry, mais le code que j'ai fourni est du C++, ça n'est certes
pas du C++ typique (tableau de char, open() & compagnie)
C'est même du C++ typique. Parfois, évidemment, c'est typique parce
qu'on ne sait pas autrement. Mais d'autres fois, parce qu'il y a des
contraints externes qui l'imposent. Ne t'en fais pas ; il m'arrive
d'écrire des choses pareilles aussi.
Ce que je voulais dire c'est que ce n'est pas parce que l'on utilise
new[], delete et les commentaires de la forme // que l'on fait du C++
(je ne juge _aucunement_ les connaissances C++ de l'initiateur du
fil).
D'abord, autant que je sache, il n'a pas de problème avec des
tableaux de char. C'est possible (voire probable) qu'il pourrait
faire ce qu'il veut avec vector. En revanche, je suppose que ce
qu'il a posté n'est pas son application complète, et c'est tout à
fait possible qu'il y a des choses ailleurs qui fait que std::vector
ne convient pas.
En passant, je serais bien intéressé par savoir quelles sont ces
choses que ne permet pas std::vector (sérieusement, ce n'est pas
ironique : je sais bien que la STL n'est pas ce qui se fait de mieux
et d'ailleurs, elle n'est pas là pour couvrir tous les cas possibles).
Les tableaux de 'char' (et d'autres types) sont des fonctionnalités
de bas niveau que tu ne devrais pas utiliser (elles sont utilisées,
entre autres, par la bibliothèque standard (STL) pour proposer des
objets de plus haut niveau comme std::string, std::vector, etc...).
Sauf que le code qu'il a posté *est* manifestement de ce bas niveau.
[...]
Un des grands avantages de C++, c'est qu'il permet l'accès à ce
niveau quand on en a besoin.
Oui, mais il me semblait pourtant que l'utilisation de fonctions POSIX
n'était pas le sujet de ce forum (je crois que open(), read() et
close() ne sont pas dans la norme C++, s'ils le sont, alors désolé,
oubliez ! :-))
Maintenant, si tu tiens absolument à programmer comme on le ferait
en C, je te suggère le groupe news:fr.comp.lang.c ...
Parce que son code ne te plaît pas, il doit aller ailleurs. Depuis
quand c'est toi qui définis les règles du groupe ?
Je n'ai aucunement parlé de règle du newsgroup. Et j'ai encore moins
défini ou imposé quoi que ce soit, ce n'est pas la peine de
s'enflammer comme ça.
Moi, j'avoue que je commence à avoir un peu marre des gens qui
envoie les autres ailleurs dès que le code ne ressemble pas à ce
qu'eux ils font en C++. Il y a des cas évident où la question est
hors sujet (comment afficher un bouton avec Windows), mais il y en a
de plus en plus où le poster est envoyé ailleurs alors que son
problème est du C++, ou est peut-être du C++.
Voir la toute dernière phrase de ce message. [*]#include <string>
#include <fstream>
#include <iostream>
#include <string>
Deux fois <string>, mais ni <istream> ni <ostream>. Sans <istream>
ni <ostream>, ce n'est pas du C++ standard.
Typo...
int main()
{
const std::string filename = "/chemin/fichier";
// Ouverture du fichier
std::ifstream inFile(filename.c_str());
Tu pourrais expliqué pourquoi le passage par std::string ?
Peut-être parce que c'est plus facile à manipuler, et qu'on ne connaît
pas forcément le nom du fichier (peut-être une entrée utilisateur ?).
Il pourrait y avoir des lignes entre le "const ..." et le
"std::ifstream ...".
Et évidemment, la sémantique de ifstream::open n'est pas celui du
open de Posix. Je suppose que s'il passe par l'open de bas niveau
(plutôt que d'utiliser des fstream ou des FILE*), c'est qu'il a
besoin des fonctionnalités qui s'y trouvent, mais qui ne se trouvent
pas dans les flux classiques. (Dans mes applications, je suis obligé
à travailler à ce niveau pour prèsque tout sauf les fichiers de
log.)if (!inFile)
{
// Traitement de l'erreur d'ouverture...
}
else
{
// Lecture du contenu
std::string data;
std::copy(std::istreambuf_iterator<std::string::value_type>(inFile),
std::istreambuf_iterator<std::string::value_type>(),
std::back_inserter(data));
Ce qui ne fait pas du tout ce qu'il a fait. Il n'a lu qu'un nombre
défini des caractères au début du fichier, non tout le fichier.
J'ai parlé de "s'inspirer" de (et donc adapter) ce code, pas de le
recopier tel quel...
Et franchement, écrire std::string::value_type à la place de char,
c'est de la masturbation mentale, ou de la complexité pour
obfusquée.
Je pense plutôt que c'est de la rigueur, mais chacun ses avis.for ( ; (i = data.find(find, i)) != std::string::npos ; )
Juste curieux, mais pourquoi « for » et non « while » ici ?
Une préférence, tout simplement !
Qui a dit "obfuscation" ? :-)
{
data.replace(i, find.length(), replace);
i += replace.length();
}
Son problème se situait à un niveau beaucoup plus bas. Et j'aimerais
bien voir la performance de ta solution avec un fichier qui consiste
en une million de ''.
J'ai toujours respecté le principe qu'il vaut mieux un programme
fiable mais lent (et qui fait ce qu'on veut) qu'un programme "rapide"
(relatif) mais qui plante.
Après, si besoin en optimisation il y a, alors on optimise.
De toutes les façons, l'initiateur du fil ne parlait aucunement
d'impératif de rapidité dans son message.
En général, sa solution est préférable à la tienne. Mais dans
l'ensemble, je n'essaierais pas une transformation en place.
Ma solution a tout de même l'avantage d'être plus portable (et donc
elle fonctionnerait vraisemblablement sous les 2 systèmes qu'il essaye
de viser).
// Ouverture du fichier en écriture
std::ofstream outFile(filename.c_str());
if (!outFile)
{
// Traitement de l'erreur d'ouverture...
Tu ésquisses le seul aspect intéressant. Qu'est-ce que tu fais si
l'ouverture échoue ici ?
L'initiateur du fil n'a pas précisé ce cas, je ne peux pas l'inventer !
D'ailleurs, dans son message, il n'y a également _aucune_ gestion des
erreurs (bien sûr, il a dit que c'était une version simplifié).
Cependant, ce n'était pas le sujet du problème.
En fait, mon commentaire sur les transformations « en place » vaut
double ici ; j'écrirais les données en sortie dans un fichier
temporaire, et seulement lors que tout c'est bien passé, je
supprimerais le fichier initial, et je rénommerais le fichier
temporaire.
Je suis également d'accord avec ce principe.
Mais ce n'est apparement pas ce qu'il voulait faire. Ma solution
"colle" donc plus à son idée de départ.
Et la gestion des erreurs ?
[...]
Et le return ? Tu ne veux sûrement pas renvoyer 0 s'il y a eu une
erreur.
Idem...
Dans l'ensemble, son essai me semblait aussi bon, sinon mieux que le
tien.
Sauf que mon compilateur ne connaît pas les fonction read() et open()
avec les seules inclusions standards... ;-)
[*] Ce qui est amusant, c'est qu'il y a déjà eu des personnes ici-même
qui se sont vues redirigées sur news:fr.comp.os.unix ou fcomp pour
moins que ça.
sorry, mais le code que j'ai fourni est du C++, ça n'est certes
pas du C++ typique (tableau de char, open() & compagnie)
C'est même du C++ typique. Parfois, évidemment, c'est typique parce
qu'on ne sait pas autrement. Mais d'autres fois, parce qu'il y a des
contraints externes qui l'imposent. Ne t'en fais pas ; il m'arrive
d'écrire des choses pareilles aussi.
Ce que je voulais dire c'est que ce n'est pas parce que l'on utilise
new[], delete et les commentaires de la forme // que l'on fait du C++
(je ne juge _aucunement_ les connaissances C++ de l'initiateur du
fil).
D'abord, autant que je sache, il n'a pas de problème avec des
tableaux de char. C'est possible (voire probable) qu'il pourrait
faire ce qu'il veut avec vector. En revanche, je suppose que ce
qu'il a posté n'est pas son application complète, et c'est tout à
fait possible qu'il y a des choses ailleurs qui fait que std::vector
ne convient pas.
En passant, je serais bien intéressé par savoir quelles sont ces
choses que ne permet pas std::vector (sérieusement, ce n'est pas
ironique : je sais bien que la STL n'est pas ce qui se fait de mieux
et d'ailleurs, elle n'est pas là pour couvrir tous les cas possibles).
Les tableaux de 'char' (et d'autres types) sont des fonctionnalités
de bas niveau que tu ne devrais pas utiliser (elles sont utilisées,
entre autres, par la bibliothèque standard (STL) pour proposer des
objets de plus haut niveau comme std::string, std::vector, etc...).
Sauf que le code qu'il a posté *est* manifestement de ce bas niveau.
[...]
Un des grands avantages de C++, c'est qu'il permet l'accès à ce
niveau quand on en a besoin.
Oui, mais il me semblait pourtant que l'utilisation de fonctions POSIX
n'était pas le sujet de ce forum (je crois que open(), read() et
close() ne sont pas dans la norme C++, s'ils le sont, alors désolé,
oubliez ! :-))
Maintenant, si tu tiens absolument à programmer comme on le ferait
en C, je te suggère le groupe news:fr.comp.lang.c ...
Parce que son code ne te plaît pas, il doit aller ailleurs. Depuis
quand c'est toi qui définis les règles du groupe ?
Je n'ai aucunement parlé de règle du newsgroup. Et j'ai encore moins
défini ou imposé quoi que ce soit, ce n'est pas la peine de
s'enflammer comme ça.
Moi, j'avoue que je commence à avoir un peu marre des gens qui
envoie les autres ailleurs dès que le code ne ressemble pas à ce
qu'eux ils font en C++. Il y a des cas évident où la question est
hors sujet (comment afficher un bouton avec Windows), mais il y en a
de plus en plus où le poster est envoyé ailleurs alors que son
problème est du C++, ou est peut-être du C++.
Voir la toute dernière phrase de ce message. [*]
#include <string>
#include <fstream>
#include <iostream>
#include <string>
Deux fois <string>, mais ni <istream> ni <ostream>. Sans <istream>
ni <ostream>, ce n'est pas du C++ standard.
Typo...
int main()
{
const std::string filename = "/chemin/fichier";
// Ouverture du fichier
std::ifstream inFile(filename.c_str());
Tu pourrais expliqué pourquoi le passage par std::string ?
Peut-être parce que c'est plus facile à manipuler, et qu'on ne connaît
pas forcément le nom du fichier (peut-être une entrée utilisateur ?).
Il pourrait y avoir des lignes entre le "const ..." et le
"std::ifstream ...".
Et évidemment, la sémantique de ifstream::open n'est pas celui du
open de Posix. Je suppose que s'il passe par l'open de bas niveau
(plutôt que d'utiliser des fstream ou des FILE*), c'est qu'il a
besoin des fonctionnalités qui s'y trouvent, mais qui ne se trouvent
pas dans les flux classiques. (Dans mes applications, je suis obligé
à travailler à ce niveau pour prèsque tout sauf les fichiers de
log.)
if (!inFile)
{
// Traitement de l'erreur d'ouverture...
}
else
{
// Lecture du contenu
std::string data;
std::copy(std::istreambuf_iterator<std::string::value_type>(inFile),
std::istreambuf_iterator<std::string::value_type>(),
std::back_inserter(data));
Ce qui ne fait pas du tout ce qu'il a fait. Il n'a lu qu'un nombre
défini des caractères au début du fichier, non tout le fichier.
J'ai parlé de "s'inspirer" de (et donc adapter) ce code, pas de le
recopier tel quel...
Et franchement, écrire std::string::value_type à la place de char,
c'est de la masturbation mentale, ou de la complexité pour
obfusquée.
Je pense plutôt que c'est de la rigueur, mais chacun ses avis.
for ( ; (i = data.find(find, i)) != std::string::npos ; )
Juste curieux, mais pourquoi « for » et non « while » ici ?
Une préférence, tout simplement !
Qui a dit "obfuscation" ? :-)
{
data.replace(i, find.length(), replace);
i += replace.length();
}
Son problème se situait à un niveau beaucoup plus bas. Et j'aimerais
bien voir la performance de ta solution avec un fichier qui consiste
en une million de '\'.
J'ai toujours respecté le principe qu'il vaut mieux un programme
fiable mais lent (et qui fait ce qu'on veut) qu'un programme "rapide"
(relatif) mais qui plante.
Après, si besoin en optimisation il y a, alors on optimise.
De toutes les façons, l'initiateur du fil ne parlait aucunement
d'impératif de rapidité dans son message.
En général, sa solution est préférable à la tienne. Mais dans
l'ensemble, je n'essaierais pas une transformation en place.
Ma solution a tout de même l'avantage d'être plus portable (et donc
elle fonctionnerait vraisemblablement sous les 2 systèmes qu'il essaye
de viser).
// Ouverture du fichier en écriture
std::ofstream outFile(filename.c_str());
if (!outFile)
{
// Traitement de l'erreur d'ouverture...
Tu ésquisses le seul aspect intéressant. Qu'est-ce que tu fais si
l'ouverture échoue ici ?
L'initiateur du fil n'a pas précisé ce cas, je ne peux pas l'inventer !
D'ailleurs, dans son message, il n'y a également _aucune_ gestion des
erreurs (bien sûr, il a dit que c'était une version simplifié).
Cependant, ce n'était pas le sujet du problème.
En fait, mon commentaire sur les transformations « en place » vaut
double ici ; j'écrirais les données en sortie dans un fichier
temporaire, et seulement lors que tout c'est bien passé, je
supprimerais le fichier initial, et je rénommerais le fichier
temporaire.
Je suis également d'accord avec ce principe.
Mais ce n'est apparement pas ce qu'il voulait faire. Ma solution
"colle" donc plus à son idée de départ.
Et la gestion des erreurs ?
[...]
Et le return ? Tu ne veux sûrement pas renvoyer 0 s'il y a eu une
erreur.
Idem...
Dans l'ensemble, son essai me semblait aussi bon, sinon mieux que le
tien.
Sauf que mon compilateur ne connaît pas les fonction read() et open()
avec les seules inclusions standards... ;-)
[*] Ce qui est amusant, c'est qu'il y a déjà eu des personnes ici-même
qui se sont vues redirigées sur news:fr.comp.os.unix ou fcomp pour
moins que ça.
sorry, mais le code que j'ai fourni est du C++, ça n'est certes
pas du C++ typique (tableau de char, open() & compagnie)
C'est même du C++ typique. Parfois, évidemment, c'est typique parce
qu'on ne sait pas autrement. Mais d'autres fois, parce qu'il y a des
contraints externes qui l'imposent. Ne t'en fais pas ; il m'arrive
d'écrire des choses pareilles aussi.
Ce que je voulais dire c'est que ce n'est pas parce que l'on utilise
new[], delete et les commentaires de la forme // que l'on fait du C++
(je ne juge _aucunement_ les connaissances C++ de l'initiateur du
fil).
D'abord, autant que je sache, il n'a pas de problème avec des
tableaux de char. C'est possible (voire probable) qu'il pourrait
faire ce qu'il veut avec vector. En revanche, je suppose que ce
qu'il a posté n'est pas son application complète, et c'est tout à
fait possible qu'il y a des choses ailleurs qui fait que std::vector
ne convient pas.
En passant, je serais bien intéressé par savoir quelles sont ces
choses que ne permet pas std::vector (sérieusement, ce n'est pas
ironique : je sais bien que la STL n'est pas ce qui se fait de mieux
et d'ailleurs, elle n'est pas là pour couvrir tous les cas possibles).
Les tableaux de 'char' (et d'autres types) sont des fonctionnalités
de bas niveau que tu ne devrais pas utiliser (elles sont utilisées,
entre autres, par la bibliothèque standard (STL) pour proposer des
objets de plus haut niveau comme std::string, std::vector, etc...).
Sauf que le code qu'il a posté *est* manifestement de ce bas niveau.
[...]
Un des grands avantages de C++, c'est qu'il permet l'accès à ce
niveau quand on en a besoin.
Oui, mais il me semblait pourtant que l'utilisation de fonctions POSIX
n'était pas le sujet de ce forum (je crois que open(), read() et
close() ne sont pas dans la norme C++, s'ils le sont, alors désolé,
oubliez ! :-))
Maintenant, si tu tiens absolument à programmer comme on le ferait
en C, je te suggère le groupe news:fr.comp.lang.c ...
Parce que son code ne te plaît pas, il doit aller ailleurs. Depuis
quand c'est toi qui définis les règles du groupe ?
Je n'ai aucunement parlé de règle du newsgroup. Et j'ai encore moins
défini ou imposé quoi que ce soit, ce n'est pas la peine de
s'enflammer comme ça.
Moi, j'avoue que je commence à avoir un peu marre des gens qui
envoie les autres ailleurs dès que le code ne ressemble pas à ce
qu'eux ils font en C++. Il y a des cas évident où la question est
hors sujet (comment afficher un bouton avec Windows), mais il y en a
de plus en plus où le poster est envoyé ailleurs alors que son
problème est du C++, ou est peut-être du C++.
Voir la toute dernière phrase de ce message. [*]#include <string>
#include <fstream>
#include <iostream>
#include <string>
Deux fois <string>, mais ni <istream> ni <ostream>. Sans <istream>
ni <ostream>, ce n'est pas du C++ standard.
Typo...
int main()
{
const std::string filename = "/chemin/fichier";
// Ouverture du fichier
std::ifstream inFile(filename.c_str());
Tu pourrais expliqué pourquoi le passage par std::string ?
Peut-être parce que c'est plus facile à manipuler, et qu'on ne connaît
pas forcément le nom du fichier (peut-être une entrée utilisateur ?).
Il pourrait y avoir des lignes entre le "const ..." et le
"std::ifstream ...".
Et évidemment, la sémantique de ifstream::open n'est pas celui du
open de Posix. Je suppose que s'il passe par l'open de bas niveau
(plutôt que d'utiliser des fstream ou des FILE*), c'est qu'il a
besoin des fonctionnalités qui s'y trouvent, mais qui ne se trouvent
pas dans les flux classiques. (Dans mes applications, je suis obligé
à travailler à ce niveau pour prèsque tout sauf les fichiers de
log.)if (!inFile)
{
// Traitement de l'erreur d'ouverture...
}
else
{
// Lecture du contenu
std::string data;
std::copy(std::istreambuf_iterator<std::string::value_type>(inFile),
std::istreambuf_iterator<std::string::value_type>(),
std::back_inserter(data));
Ce qui ne fait pas du tout ce qu'il a fait. Il n'a lu qu'un nombre
défini des caractères au début du fichier, non tout le fichier.
J'ai parlé de "s'inspirer" de (et donc adapter) ce code, pas de le
recopier tel quel...
Et franchement, écrire std::string::value_type à la place de char,
c'est de la masturbation mentale, ou de la complexité pour
obfusquée.
Je pense plutôt que c'est de la rigueur, mais chacun ses avis.for ( ; (i = data.find(find, i)) != std::string::npos ; )
Juste curieux, mais pourquoi « for » et non « while » ici ?
Une préférence, tout simplement !
Qui a dit "obfuscation" ? :-)
{
data.replace(i, find.length(), replace);
i += replace.length();
}
Son problème se situait à un niveau beaucoup plus bas. Et j'aimerais
bien voir la performance de ta solution avec un fichier qui consiste
en une million de ''.
J'ai toujours respecté le principe qu'il vaut mieux un programme
fiable mais lent (et qui fait ce qu'on veut) qu'un programme "rapide"
(relatif) mais qui plante.
Après, si besoin en optimisation il y a, alors on optimise.
De toutes les façons, l'initiateur du fil ne parlait aucunement
d'impératif de rapidité dans son message.
En général, sa solution est préférable à la tienne. Mais dans
l'ensemble, je n'essaierais pas une transformation en place.
Ma solution a tout de même l'avantage d'être plus portable (et donc
elle fonctionnerait vraisemblablement sous les 2 systèmes qu'il essaye
de viser).
// Ouverture du fichier en écriture
std::ofstream outFile(filename.c_str());
if (!outFile)
{
// Traitement de l'erreur d'ouverture...
Tu ésquisses le seul aspect intéressant. Qu'est-ce que tu fais si
l'ouverture échoue ici ?
L'initiateur du fil n'a pas précisé ce cas, je ne peux pas l'inventer !
D'ailleurs, dans son message, il n'y a également _aucune_ gestion des
erreurs (bien sûr, il a dit que c'était une version simplifié).
Cependant, ce n'était pas le sujet du problème.
En fait, mon commentaire sur les transformations « en place » vaut
double ici ; j'écrirais les données en sortie dans un fichier
temporaire, et seulement lors que tout c'est bien passé, je
supprimerais le fichier initial, et je rénommerais le fichier
temporaire.
Je suis également d'accord avec ce principe.
Mais ce n'est apparement pas ce qu'il voulait faire. Ma solution
"colle" donc plus à son idée de départ.
Et la gestion des erreurs ?
[...]
Et le return ? Tu ne veux sûrement pas renvoyer 0 s'il y a eu une
erreur.
Idem...
Dans l'ensemble, son essai me semblait aussi bon, sinon mieux que le
tien.
Sauf que mon compilateur ne connaît pas les fonction read() et open()
avec les seules inclusions standards... ;-)
[*] Ce qui est amusant, c'est qu'il y a déjà eu des personnes ici-même
qui se sont vues redirigées sur news:fr.comp.os.unix ou fcomp pour
moins que ça.
Vincent Richard wrote
in message news:<3fa7cf3c$0$27031$...sorry, mais le code que j'ai fourni est du C++, ça n'est certes
pas du C++ typique (tableau de char, open() & compagnie)
C'est même du C++ typique. Parfois, évidemment, c'est typique parce
qu'on ne sait pas autrement. Mais d'autres fois, parce qu'il y a des
contraints externes qui l'imposent. Ne t'en fais pas ; il m'arrive
d'écrire des choses pareilles aussi.
Ce que je voulais dire c'est que ce n'est pas parce que l'on utilise
new[], delete et les commentaires de la forme // que l'on fait du C++
(je ne juge _aucunement_ les connaissances C++ de l'initiateur du
fil).
Et si ce n'est pas du C++, c'est quoi, alors ? Il y a beaucoup de façons
à utiliser le C++. Sans savoir toutes ces contraintes, je suis incapable
à dire quelle est la façon qui lui convient le plus.
En passant, je serais bien intéressé par savoir quelles sont ces
choses que ne permet pas std::vector (sérieusement, ce n'est pas
ironique : je sais bien que la STL n'est pas ce qui se fait de mieux
et d'ailleurs, elle n'est pas là pour couvrir tous les cas possibles).
Beaucoup. Le plus évident, évidemment, c'est quand tu dois supporter un
compilateur ancient qui ne l'a pas:-).
Autrement, quand il faut passer le tableau (y compris la responsabilité
de l'effacement) à une fonction qui s'attend à un T*. On ne peut se
servir de std::vector dans ce cas QUE si la durée de vie qu'il donne
convient -- c'est souvent le cas, mais pas forcement toujours.
Un autre cas, c'est l'implémentation des choses de très bas niveau. Si
c'est évident qu'on ne peut pas se servir de std::vector dans
l'implémentation de std::vector, je le vois mal aussi dans
l'implémentation de std::string. Et je n'exclurais pas d'office qu'il y
a des classes semblables propre à l'application.
Finalement, il y a des cas où c'est simplement trop lourd -- considère
quelque chose du genre :
Les tableaux de 'char' (et d'autres types) sont des fonctionnalités
de bas niveau que tu ne devrais pas utiliser (elles sont utilisées,
entre autres, par la bibliothèque standard (STL) pour proposer des
objets de plus haut niveau comme std::string, std::vector, etc...).
Sauf que le code qu'il a posté *est* manifestement de ce bas niveau.
Maintenant, si tu tiens absolument à programmer comme on le ferait
en C, je te suggère le groupe news:fr.comp.lang.c ...
Parce que son code ne te plaît pas, il doit aller ailleurs. Depuis
quand c'est toi qui définis les règles du groupe ?
Je n'ai aucunement parlé de règle du newsgroup. Et j'ai encore moins
défini ou imposé quoi que ce soit, ce n'est pas la peine de
s'enflammer comme ça.
Je ne te vise pas particulièrement, mais je constate depuis un certain
temps que certains passent plus de temps à essayer à signaler des hors
sujets que de faire des contributions constructives.
#include <string>
#include <fstream>
#include <iostream>
#include <string>
Deux fois <string>, mais ni <istream> ni <ostream>. Sans <istream>
ni <ostream>, ce n'est pas du C++ standard.
Typo...
D'accord. En ce qui concerne la duplication de <string>, je m'en doutais
un peu. Mais je vois très souvent des postes avec #include <iostream>,
mais sans le <istream> ou le <ostream>.
En passant, tu as aussi oublié <iterator> et <algorithm>.
Ma solution a tout de même l'avantage d'être plus portable (et donc
elle fonctionnerait vraisemblablement sous les 2 systèmes qu'il essaye
de viser).
Portable est rélative. Elle ne fonctionne pas dans l'environement de
production où je travaille.
Mais note bien qu'il y a deux questions indépendantes : comment formuler
l'algorithme, et le choix des entrées/sorties. Je suis bien d'accord que
quand on peut, il vaut mieux se servir des iostream, sinon les FILE*, et
seulement en dernière ligne les entrées/sorties du système. N'empêche
que les garanties données par la norme pour les iostream et les FILE ne
suffisent que rarement, et que pour tout ce qui est critique, on est
obligé à passer par les requêtes Posix.
Sauf que mon compilateur ne connaît pas les fonction read() et open()
avec les seules inclusions standards... ;-)
Mais ce n'est pas un aspect important de sa solution. Et dans la
pratique, on ne peut pas écrire une application utile avec les seules
inclusions standards.
Vincent Richard <chere-loque.MARRE-DE-LA-PUB@wanadoo.fr.invalid> wrote
in message news:<3fa7cf3c$0$27031$626a54ce@news.free.fr>...
sorry, mais le code que j'ai fourni est du C++, ça n'est certes
pas du C++ typique (tableau de char, open() & compagnie)
C'est même du C++ typique. Parfois, évidemment, c'est typique parce
qu'on ne sait pas autrement. Mais d'autres fois, parce qu'il y a des
contraints externes qui l'imposent. Ne t'en fais pas ; il m'arrive
d'écrire des choses pareilles aussi.
Ce que je voulais dire c'est que ce n'est pas parce que l'on utilise
new[], delete et les commentaires de la forme // que l'on fait du C++
(je ne juge _aucunement_ les connaissances C++ de l'initiateur du
fil).
Et si ce n'est pas du C++, c'est quoi, alors ? Il y a beaucoup de façons
à utiliser le C++. Sans savoir toutes ces contraintes, je suis incapable
à dire quelle est la façon qui lui convient le plus.
En passant, je serais bien intéressé par savoir quelles sont ces
choses que ne permet pas std::vector (sérieusement, ce n'est pas
ironique : je sais bien que la STL n'est pas ce qui se fait de mieux
et d'ailleurs, elle n'est pas là pour couvrir tous les cas possibles).
Beaucoup. Le plus évident, évidemment, c'est quand tu dois supporter un
compilateur ancient qui ne l'a pas:-).
Autrement, quand il faut passer le tableau (y compris la responsabilité
de l'effacement) à une fonction qui s'attend à un T*. On ne peut se
servir de std::vector dans ce cas QUE si la durée de vie qu'il donne
convient -- c'est souvent le cas, mais pas forcement toujours.
Un autre cas, c'est l'implémentation des choses de très bas niveau. Si
c'est évident qu'on ne peut pas se servir de std::vector dans
l'implémentation de std::vector, je le vois mal aussi dans
l'implémentation de std::string. Et je n'exclurais pas d'office qu'il y
a des classes semblables propre à l'application.
Finalement, il y a des cas où c'est simplement trop lourd -- considère
quelque chose du genre :
Les tableaux de 'char' (et d'autres types) sont des fonctionnalités
de bas niveau que tu ne devrais pas utiliser (elles sont utilisées,
entre autres, par la bibliothèque standard (STL) pour proposer des
objets de plus haut niveau comme std::string, std::vector, etc...).
Sauf que le code qu'il a posté *est* manifestement de ce bas niveau.
Maintenant, si tu tiens absolument à programmer comme on le ferait
en C, je te suggère le groupe news:fr.comp.lang.c ...
Parce que son code ne te plaît pas, il doit aller ailleurs. Depuis
quand c'est toi qui définis les règles du groupe ?
Je n'ai aucunement parlé de règle du newsgroup. Et j'ai encore moins
défini ou imposé quoi que ce soit, ce n'est pas la peine de
s'enflammer comme ça.
Je ne te vise pas particulièrement, mais je constate depuis un certain
temps que certains passent plus de temps à essayer à signaler des hors
sujets que de faire des contributions constructives.
#include <string>
#include <fstream>
#include <iostream>
#include <string>
Deux fois <string>, mais ni <istream> ni <ostream>. Sans <istream>
ni <ostream>, ce n'est pas du C++ standard.
Typo...
D'accord. En ce qui concerne la duplication de <string>, je m'en doutais
un peu. Mais je vois très souvent des postes avec #include <iostream>,
mais sans le <istream> ou le <ostream>.
En passant, tu as aussi oublié <iterator> et <algorithm>.
Ma solution a tout de même l'avantage d'être plus portable (et donc
elle fonctionnerait vraisemblablement sous les 2 systèmes qu'il essaye
de viser).
Portable est rélative. Elle ne fonctionne pas dans l'environement de
production où je travaille.
Mais note bien qu'il y a deux questions indépendantes : comment formuler
l'algorithme, et le choix des entrées/sorties. Je suis bien d'accord que
quand on peut, il vaut mieux se servir des iostream, sinon les FILE*, et
seulement en dernière ligne les entrées/sorties du système. N'empêche
que les garanties données par la norme pour les iostream et les FILE ne
suffisent que rarement, et que pour tout ce qui est critique, on est
obligé à passer par les requêtes Posix.
Sauf que mon compilateur ne connaît pas les fonction read() et open()
avec les seules inclusions standards... ;-)
Mais ce n'est pas un aspect important de sa solution. Et dans la
pratique, on ne peut pas écrire une application utile avec les seules
inclusions standards.
Vincent Richard wrote
in message news:<3fa7cf3c$0$27031$...sorry, mais le code que j'ai fourni est du C++, ça n'est certes
pas du C++ typique (tableau de char, open() & compagnie)
C'est même du C++ typique. Parfois, évidemment, c'est typique parce
qu'on ne sait pas autrement. Mais d'autres fois, parce qu'il y a des
contraints externes qui l'imposent. Ne t'en fais pas ; il m'arrive
d'écrire des choses pareilles aussi.
Ce que je voulais dire c'est que ce n'est pas parce que l'on utilise
new[], delete et les commentaires de la forme // que l'on fait du C++
(je ne juge _aucunement_ les connaissances C++ de l'initiateur du
fil).
Et si ce n'est pas du C++, c'est quoi, alors ? Il y a beaucoup de façons
à utiliser le C++. Sans savoir toutes ces contraintes, je suis incapable
à dire quelle est la façon qui lui convient le plus.
En passant, je serais bien intéressé par savoir quelles sont ces
choses que ne permet pas std::vector (sérieusement, ce n'est pas
ironique : je sais bien que la STL n'est pas ce qui se fait de mieux
et d'ailleurs, elle n'est pas là pour couvrir tous les cas possibles).
Beaucoup. Le plus évident, évidemment, c'est quand tu dois supporter un
compilateur ancient qui ne l'a pas:-).
Autrement, quand il faut passer le tableau (y compris la responsabilité
de l'effacement) à une fonction qui s'attend à un T*. On ne peut se
servir de std::vector dans ce cas QUE si la durée de vie qu'il donne
convient -- c'est souvent le cas, mais pas forcement toujours.
Un autre cas, c'est l'implémentation des choses de très bas niveau. Si
c'est évident qu'on ne peut pas se servir de std::vector dans
l'implémentation de std::vector, je le vois mal aussi dans
l'implémentation de std::string. Et je n'exclurais pas d'office qu'il y
a des classes semblables propre à l'application.
Finalement, il y a des cas où c'est simplement trop lourd -- considère
quelque chose du genre :
Les tableaux de 'char' (et d'autres types) sont des fonctionnalités
de bas niveau que tu ne devrais pas utiliser (elles sont utilisées,
entre autres, par la bibliothèque standard (STL) pour proposer des
objets de plus haut niveau comme std::string, std::vector, etc...).
Sauf que le code qu'il a posté *est* manifestement de ce bas niveau.
Maintenant, si tu tiens absolument à programmer comme on le ferait
en C, je te suggère le groupe news:fr.comp.lang.c ...
Parce que son code ne te plaît pas, il doit aller ailleurs. Depuis
quand c'est toi qui définis les règles du groupe ?
Je n'ai aucunement parlé de règle du newsgroup. Et j'ai encore moins
défini ou imposé quoi que ce soit, ce n'est pas la peine de
s'enflammer comme ça.
Je ne te vise pas particulièrement, mais je constate depuis un certain
temps que certains passent plus de temps à essayer à signaler des hors
sujets que de faire des contributions constructives.
#include <string>
#include <fstream>
#include <iostream>
#include <string>
Deux fois <string>, mais ni <istream> ni <ostream>. Sans <istream>
ni <ostream>, ce n'est pas du C++ standard.
Typo...
D'accord. En ce qui concerne la duplication de <string>, je m'en doutais
un peu. Mais je vois très souvent des postes avec #include <iostream>,
mais sans le <istream> ou le <ostream>.
En passant, tu as aussi oublié <iterator> et <algorithm>.
Ma solution a tout de même l'avantage d'être plus portable (et donc
elle fonctionnerait vraisemblablement sous les 2 systèmes qu'il essaye
de viser).
Portable est rélative. Elle ne fonctionne pas dans l'environement de
production où je travaille.
Mais note bien qu'il y a deux questions indépendantes : comment formuler
l'algorithme, et le choix des entrées/sorties. Je suis bien d'accord que
quand on peut, il vaut mieux se servir des iostream, sinon les FILE*, et
seulement en dernière ligne les entrées/sorties du système. N'empêche
que les garanties données par la norme pour les iostream et les FILE ne
suffisent que rarement, et que pour tout ce qui est critique, on est
obligé à passer par les requêtes Posix.
Sauf que mon compilateur ne connaît pas les fonction read() et open()
avec les seules inclusions standards... ;-)
Mais ce n'est pas un aspect important de sa solution. Et dans la
pratique, on ne peut pas écrire une application utile avec les seules
inclusions standards.
Vincent Richard
wrote in message news:<3fa7cf3c$0$27031$...
Ce que je voulais dire c'est que ce n'est pas parce que l'on
utilise new[], delete et les commentaires de la forme // que l'on
fait du C++ (je ne juge _aucunement_ les connaissances C++ de
l'initiateur du fil).
Et si ce n'est pas du C++, c'est quoi, alors ? Il y a beaucoup de
façons à utiliser le C++. Sans savoir toutes ces contraintes, je
suis incapable à dire quelle est la façon qui lui convient le plus.
C'est bien du C++, mais pas dans le sens où je l'entendais : dans mes
^^
projets, je m'efforce d'utiliser le plus possible la STL car elle est
(en théorie) portable, et très efficace (bien optimisée par les
développeurs de compilateurs), donc pourquoi vouloir réinventer la
roue à chaque fois ?
Sauf évidemment, comme tu l'as dis, qu'il y peut y avoir des
contraintes que l'on ne connaît pas, et comme je ne les connais pas
non plus, j'ai proposé l'utilisation de la STL...
Sauf que le code qu'il a posté *est* manifestement de ce bas
niveau.
Et ma vrai question était : "est-ce vraiment la peine de passer à un
niveau aussi bas pour faire ce qu'il veut faire ?".
Maintenant, il faut peser le pour et le contre, selon ce qu'il veut
comme portabilité/fonctionnalité/performance. Et encore une fois,
j'insiste, il n'en a fait aucunement mention dans son message.
Maintenant, si tu tiens absolument à programmer comme on le
ferait en C, je te suggère le groupe news:fr.comp.lang.c ...
Parce que son code ne te plaît pas, il doit aller
ailleurs. Depuis quand c'est toi qui définis les règles du groupe
?
Je n'ai aucunement parlé de règle du newsgroup. Et j'ai encore moins
défini ou imposé quoi que ce soit, ce n'est pas la peine de
s'enflammer comme ça.
Je ne te vise pas particulièrement, mais je constate depuis un
certain temps que certains passent plus de temps à essayer à
signaler des hors sujets que de faire des contributions
constructives.
Malheureusement, on constate aussi qu'il y a de plus en plus de
messages HS et aussi de personnes qui ne consultent pas les chartes
des groupes avant d'y poster.
#include <string>
#include <fstream>
#include <iostream>
#include <string>
Deux fois <string>, mais ni <istream> ni <ostream>. Sans
<istream> ni <ostream>, ce n'est pas du C++ standard.
Typo...
D'accord. En ce qui concerne la duplication de <string>, je m'en
doutais un peu. Mais je vois très souvent des postes avec #include
<iostream>, mais sans le <istream> ou le <ostream>.
Oui, en effet (surtout qu'il me semble que c'est grâce à un de tes
posts que j'avais appris ça).
En passant, tu as aussi oublié <iterator> et <algorithm>.
D'ailleurs, c'est tout de même assez embêtant que mon compilateur (g++
3.2.2 / Linux) ne me fasse pas part de ces problèmes d'inclusion... Si
quelqu'un a la solution (j'utilise pourtant les flags -ansi -pedantic
-Wall).
La norme impose-t-elle que le programme ne doit pas compiler ou bien
elle impose seulement que si ces inclusions ne sont pas présentes,
alors le programme "a le droit" de ne pas fonctionner ?
Vincent Richard <chere-loque.MARRE-DE-LA-PUB@wanadoo.fr.invalid>
wrote in message news:<3fa7cf3c$0$27031$626a54ce@news.free.fr>...
Ce que je voulais dire c'est que ce n'est pas parce que l'on
utilise new[], delete et les commentaires de la forme // que l'on
fait du C++ (je ne juge _aucunement_ les connaissances C++ de
l'initiateur du fil).
Et si ce n'est pas du C++, c'est quoi, alors ? Il y a beaucoup de
façons à utiliser le C++. Sans savoir toutes ces contraintes, je
suis incapable à dire quelle est la façon qui lui convient le plus.
C'est bien du C++, mais pas dans le sens où je l'entendais : dans mes
^^
projets, je m'efforce d'utiliser le plus possible la STL car elle est
(en théorie) portable, et très efficace (bien optimisée par les
développeurs de compilateurs), donc pourquoi vouloir réinventer la
roue à chaque fois ?
Sauf évidemment, comme tu l'as dis, qu'il y peut y avoir des
contraintes que l'on ne connaît pas, et comme je ne les connais pas
non plus, j'ai proposé l'utilisation de la STL...
Sauf que le code qu'il a posté *est* manifestement de ce bas
niveau.
Et ma vrai question était : "est-ce vraiment la peine de passer à un
niveau aussi bas pour faire ce qu'il veut faire ?".
Maintenant, il faut peser le pour et le contre, selon ce qu'il veut
comme portabilité/fonctionnalité/performance. Et encore une fois,
j'insiste, il n'en a fait aucunement mention dans son message.
Maintenant, si tu tiens absolument à programmer comme on le
ferait en C, je te suggère le groupe news:fr.comp.lang.c ...
Parce que son code ne te plaît pas, il doit aller
ailleurs. Depuis quand c'est toi qui définis les règles du groupe
?
Je n'ai aucunement parlé de règle du newsgroup. Et j'ai encore moins
défini ou imposé quoi que ce soit, ce n'est pas la peine de
s'enflammer comme ça.
Je ne te vise pas particulièrement, mais je constate depuis un
certain temps que certains passent plus de temps à essayer à
signaler des hors sujets que de faire des contributions
constructives.
Malheureusement, on constate aussi qu'il y a de plus en plus de
messages HS et aussi de personnes qui ne consultent pas les chartes
des groupes avant d'y poster.
#include <string>
#include <fstream>
#include <iostream>
#include <string>
Deux fois <string>, mais ni <istream> ni <ostream>. Sans
<istream> ni <ostream>, ce n'est pas du C++ standard.
Typo...
D'accord. En ce qui concerne la duplication de <string>, je m'en
doutais un peu. Mais je vois très souvent des postes avec #include
<iostream>, mais sans le <istream> ou le <ostream>.
Oui, en effet (surtout qu'il me semble que c'est grâce à un de tes
posts que j'avais appris ça).
En passant, tu as aussi oublié <iterator> et <algorithm>.
D'ailleurs, c'est tout de même assez embêtant que mon compilateur (g++
3.2.2 / Linux) ne me fasse pas part de ces problèmes d'inclusion... Si
quelqu'un a la solution (j'utilise pourtant les flags -ansi -pedantic
-Wall).
La norme impose-t-elle que le programme ne doit pas compiler ou bien
elle impose seulement que si ces inclusions ne sont pas présentes,
alors le programme "a le droit" de ne pas fonctionner ?
Vincent Richard
wrote in message news:<3fa7cf3c$0$27031$...
Ce que je voulais dire c'est que ce n'est pas parce que l'on
utilise new[], delete et les commentaires de la forme // que l'on
fait du C++ (je ne juge _aucunement_ les connaissances C++ de
l'initiateur du fil).
Et si ce n'est pas du C++, c'est quoi, alors ? Il y a beaucoup de
façons à utiliser le C++. Sans savoir toutes ces contraintes, je
suis incapable à dire quelle est la façon qui lui convient le plus.
C'est bien du C++, mais pas dans le sens où je l'entendais : dans mes
^^
projets, je m'efforce d'utiliser le plus possible la STL car elle est
(en théorie) portable, et très efficace (bien optimisée par les
développeurs de compilateurs), donc pourquoi vouloir réinventer la
roue à chaque fois ?
Sauf évidemment, comme tu l'as dis, qu'il y peut y avoir des
contraintes que l'on ne connaît pas, et comme je ne les connais pas
non plus, j'ai proposé l'utilisation de la STL...
Sauf que le code qu'il a posté *est* manifestement de ce bas
niveau.
Et ma vrai question était : "est-ce vraiment la peine de passer à un
niveau aussi bas pour faire ce qu'il veut faire ?".
Maintenant, il faut peser le pour et le contre, selon ce qu'il veut
comme portabilité/fonctionnalité/performance. Et encore une fois,
j'insiste, il n'en a fait aucunement mention dans son message.
Maintenant, si tu tiens absolument à programmer comme on le
ferait en C, je te suggère le groupe news:fr.comp.lang.c ...
Parce que son code ne te plaît pas, il doit aller
ailleurs. Depuis quand c'est toi qui définis les règles du groupe
?
Je n'ai aucunement parlé de règle du newsgroup. Et j'ai encore moins
défini ou imposé quoi que ce soit, ce n'est pas la peine de
s'enflammer comme ça.
Je ne te vise pas particulièrement, mais je constate depuis un
certain temps que certains passent plus de temps à essayer à
signaler des hors sujets que de faire des contributions
constructives.
Malheureusement, on constate aussi qu'il y a de plus en plus de
messages HS et aussi de personnes qui ne consultent pas les chartes
des groupes avant d'y poster.
#include <string>
#include <fstream>
#include <iostream>
#include <string>
Deux fois <string>, mais ni <istream> ni <ostream>. Sans
<istream> ni <ostream>, ce n'est pas du C++ standard.
Typo...
D'accord. En ce qui concerne la duplication de <string>, je m'en
doutais un peu. Mais je vois très souvent des postes avec #include
<iostream>, mais sans le <istream> ou le <ostream>.
Oui, en effet (surtout qu'il me semble que c'est grâce à un de tes
posts que j'avais appris ça).
En passant, tu as aussi oublié <iterator> et <algorithm>.
D'ailleurs, c'est tout de même assez embêtant que mon compilateur (g++
3.2.2 / Linux) ne me fasse pas part de ces problèmes d'inclusion... Si
quelqu'un a la solution (j'utilise pourtant les flags -ansi -pedantic
-Wall).
La norme impose-t-elle que le programme ne doit pas compiler ou bien
elle impose seulement que si ces inclusions ne sont pas présentes,
alors le programme "a le droit" de ne pas fonctionner ?
Vincent Richard wrote
in message news:<3fa8ec7b$0$10432$...Vincent Richard
wrote in message news:<3fa7cf3c$0$27031$...
C'est bien du C++, mais pas dans le sens où je l'entendais : dans mes
^^
Et c'est précisement ça que je te réproche. De vouloir imposer le sens
que TU l'entends à tout le monde, en disant que ce n'est pas du C++, et
qu'il doit aller ailleurs.
Vincent Richard <chere-loque.MARRE-DE-LA-PUB@wanadoo.fr.invalid> wrote
in message news:<3fa8ec7b$0$10432$626a54ce@news.free.fr>...
Vincent Richard <chere-loque.MARRE-DE-LA-PUB@wanadoo.fr.invalid>
wrote in message news:<3fa7cf3c$0$27031$626a54ce@news.free.fr>...
C'est bien du C++, mais pas dans le sens où je l'entendais : dans mes
^^
Et c'est précisement ça que je te réproche. De vouloir imposer le sens
que TU l'entends à tout le monde, en disant que ce n'est pas du C++, et
qu'il doit aller ailleurs.
Vincent Richard wrote
in message news:<3fa8ec7b$0$10432$...Vincent Richard
wrote in message news:<3fa7cf3c$0$27031$...
C'est bien du C++, mais pas dans le sens où je l'entendais : dans mes
^^
Et c'est précisement ça que je te réproche. De vouloir imposer le sens
que TU l'entends à tout le monde, en disant que ce n'est pas du C++, et
qu'il doit aller ailleurs.
Et Herb Sutter insiste bien sur le fait de ne pas écrire du code
qu'on ne maîtrise pas, et propose un ratio 90%/10% entre ce qu'on
maîtrise et les choses qu'on découvre.
Et Herb Sutter insiste bien sur le fait de ne pas écrire du code
qu'on ne maîtrise pas, et propose un ratio 90%/10% entre ce qu'on
maîtrise et les choses qu'on découvre.
Et Herb Sutter insiste bien sur le fait de ne pas écrire du code
qu'on ne maîtrise pas, et propose un ratio 90%/10% entre ce qu'on
maîtrise et les choses qu'on découvre.
Marc Boyer wrote in message
news:<bocv9q$k3m$...Et Herb Sutter insiste bien sur le fait de ne pas écrire du code
qu'on ne maîtrise pas, et propose un ratio 90%/10% entre ce qu'on
maîtrise et les choses qu'on découvre.
Tu peux m'indiquer une citation ?
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<bocv9q$k3m$3@news.cict.fr>...
Et Herb Sutter insiste bien sur le fait de ne pas écrire du code
qu'on ne maîtrise pas, et propose un ratio 90%/10% entre ce qu'on
maîtrise et les choses qu'on découvre.
Tu peux m'indiquer une citation ?
Marc Boyer wrote in message
news:<bocv9q$k3m$...Et Herb Sutter insiste bien sur le fait de ne pas écrire du code
qu'on ne maîtrise pas, et propose un ratio 90%/10% entre ce qu'on
maîtrise et les choses qu'on découvre.
Tu peux m'indiquer une citation ?
