ofstream et vérification de l'existence d'un fichier
18 réponses
oxidor trucidel
J'ai essayé le truc de Loic avec ofstream sans fichier de sauvegarde,
j'obtient plusieurs erreurs à la ligne if (!os(close))
Du coup, je prends mon petit lexique c++ au chapitre ofstream et
je lis "comportement par défaut: s'il ne trouve pas le fichier que vous
voulez ouvrir, il en crée un".
Si le fichier est créé par l'instruction, est-ce utile de vérifier son
existence ?
Bon, je me remets au boulot... mais je crois bien que je ne tarderai pas
à revenir avec une autre question.
| "oxidor trucidel" writes: | | > "drkm" a écrit: | | >> "oxidor trucidel" writes: | | >>> J'ai essayé le truc de Loic avec ofstream sans fichier de sauvegarde, | >>> j'obtient plusieurs erreurs à la ligne if (!os(close)) | | >> Loïc a vraiment écrit cela ? | | > Heu... c'est sa première réponse, j'ai sauté dessus pour faire un essai | > sans attendre la suite. | | | if ( ! os.close() ) | | Et comme tu le sous-entend, il s'est repris par la suite. | | Au fait, pourquoi std::basic_fstream<>::close() ne retourne-t-elle | pas ce que lui retourne std::basic_filebuf<>::close() ? Voire une | référence vers le flux, convertible en booléen. De manière à pouvoir | écrire le test ci-dessus. Y a-t-il une motivation derrière cette | décision ?
Aucune idée.
Il y a très longtemps, j'avais lu une règle de codage qui disait qu'une fonction ne devrait pas renvoyer void, que si elle ne savait pas quoi retourner, elle n'avait qu'à retourner une référence à *this. Il semble que ce ne soit pas une règle très populaire :-)
-- Gaby
drkm <usenet.fclcxx@fgeorges.org> writes:
| "oxidor trucidel" <oxidor@uf.net> writes:
|
| > "drkm" <usenet.fclcxx@fgeorges.org> a écrit:
|
| >> "oxidor trucidel" <oxidor@uf.net> writes:
|
| >>> J'ai essayé le truc de Loic avec ofstream sans fichier de sauvegarde,
| >>> j'obtient plusieurs erreurs à la ligne if (!os(close))
|
| >> Loïc a vraiment écrit cela ?
|
| > Heu... c'est sa première réponse, j'ai sauté dessus pour faire un essai
| > sans attendre la suite.
|
|
| if ( ! os.close() )
|
| Et comme tu le sous-entend, il s'est repris par la suite.
|
| Au fait, pourquoi std::basic_fstream<>::close() ne retourne-t-elle
| pas ce que lui retourne std::basic_filebuf<>::close() ? Voire une
| référence vers le flux, convertible en booléen. De manière à pouvoir
| écrire le test ci-dessus. Y a-t-il une motivation derrière cette
| décision ?
Aucune idée.
Il y a très longtemps, j'avais lu une règle de codage qui disait
qu'une fonction ne devrait pas renvoyer void, que si elle ne savait
pas quoi retourner, elle n'avait qu'à retourner une référence à *this.
Il semble que ce ne soit pas une règle très populaire :-)
| "oxidor trucidel" writes: | | > "drkm" a écrit: | | >> "oxidor trucidel" writes: | | >>> J'ai essayé le truc de Loic avec ofstream sans fichier de sauvegarde, | >>> j'obtient plusieurs erreurs à la ligne if (!os(close)) | | >> Loïc a vraiment écrit cela ? | | > Heu... c'est sa première réponse, j'ai sauté dessus pour faire un essai | > sans attendre la suite. | | | if ( ! os.close() ) | | Et comme tu le sous-entend, il s'est repris par la suite. | | Au fait, pourquoi std::basic_fstream<>::close() ne retourne-t-elle | pas ce que lui retourne std::basic_filebuf<>::close() ? Voire une | référence vers le flux, convertible en booléen. De manière à pouvoir | écrire le test ci-dessus. Y a-t-il une motivation derrière cette | décision ?
Aucune idée.
Il y a très longtemps, j'avais lu une règle de codage qui disait qu'une fonction ne devrait pas renvoyer void, que si elle ne savait pas quoi retourner, elle n'avait qu'à retourner une référence à *this. Il semble que ce ne soit pas une règle très populaire :-)
-- Gaby
oxidor trucidel
"Fabien LE LEZ" a écrit dans le message de news:
On Sat, 14 Aug 2004 13:38:44 +0200, "oxidor trucidel" :
Ah, j'ai la nostalgie de QBasic, tout à coup. ;-)
QBasic permettait de détecter si un fichier existe ?
Il permet en tout cas de gérer les répertoires beaucoup plus facilement.
Remarque, si tu veux faire du spécifique-Windows, utilise les fonctions de l'API Win32 qui vont bien, la gestion d'erreur n'en sera que plus fine.
Je ne veux pas de spécifique windows, j'aurais trop de mal à convertir par la suite pour une autre platteforme.
-- Oxidor Trucidel
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news:7g0sh0pfi3a766miigmjhui704prpnkf9j@4ax.com...
On Sat, 14 Aug 2004 13:38:44 +0200, "oxidor trucidel" <oxidor@uf.net>:
Ah, j'ai la nostalgie de QBasic, tout à coup. ;-)
QBasic permettait de détecter si un fichier existe ?
Il permet en tout cas de gérer les répertoires beaucoup
plus facilement.
Remarque, si tu veux faire du spécifique-Windows, utilise les
fonctions de l'API Win32 qui vont bien, la gestion d'erreur n'en sera
que plus fine.
Je ne veux pas de spécifique windows, j'aurais trop de mal à convertir
par la suite pour une autre platteforme.
On Sat, 14 Aug 2004 13:38:44 +0200, "oxidor trucidel" :
Ah, j'ai la nostalgie de QBasic, tout à coup. ;-)
QBasic permettait de détecter si un fichier existe ?
Il permet en tout cas de gérer les répertoires beaucoup plus facilement.
Remarque, si tu veux faire du spécifique-Windows, utilise les fonctions de l'API Win32 qui vont bien, la gestion d'erreur n'en sera que plus fine.
Je ne veux pas de spécifique windows, j'aurais trop de mal à convertir par la suite pour une autre platteforme.
-- Oxidor Trucidel
oxidor trucidel
"drkm" a écrit dans le message de news:
"oxidor trucidel" writes:
"drkm" a écrit:
"oxidor trucidel" writes:
J'ai essayé le truc de Loic avec ofstream sans fichier de sauvegarde, j'obtient plusieurs erreurs à la ligne if (!os(close))
Loïc a vraiment écrit cela ?
Heu... c'est sa première réponse, j'ai sauté dessus pour faire un essai sans attendre la suite.
if ( ! os.close() )
Et comme tu le sous-entend, il s'est repris par la suite.
Au fait, pourquoi std::basic_fstream<>::close() ne retourne-t-elle pas ce que lui retourne std::basic_filebuf<>::close() ? Voire une référence vers le flux, convertible en booléen. De manière à pouvoir écrire le test ci-dessus. Y a-t-il une motivation derrière cette décision ?
Heu... j'espère que ce n'est pas à moi que tu poses cette question.
-- Oxidor Trucidel
"drkm" <usenet.fclcxx@fgeorges.org> a écrit dans le message de
news:wkhdr5lx0n.fsf@fgeorges.org...
"oxidor trucidel" <oxidor@uf.net> writes:
"drkm" <usenet.fclcxx@fgeorges.org> a écrit:
"oxidor trucidel" <oxidor@uf.net> writes:
J'ai essayé le truc de Loic avec ofstream sans fichier de sauvegarde,
j'obtient plusieurs erreurs à la ligne if (!os(close))
Loïc a vraiment écrit cela ?
Heu... c'est sa première réponse, j'ai sauté dessus pour faire un essai
sans attendre la suite.
if ( ! os.close() )
Et comme tu le sous-entend, il s'est repris par la suite.
Au fait, pourquoi std::basic_fstream<>::close() ne retourne-t-elle
pas ce que lui retourne std::basic_filebuf<>::close() ? Voire une
référence vers le flux, convertible en booléen. De manière à pouvoir
écrire le test ci-dessus. Y a-t-il une motivation derrière cette
décision ?
Heu... j'espère que ce n'est pas à moi que tu poses cette question.
J'ai essayé le truc de Loic avec ofstream sans fichier de sauvegarde, j'obtient plusieurs erreurs à la ligne if (!os(close))
Loïc a vraiment écrit cela ?
Heu... c'est sa première réponse, j'ai sauté dessus pour faire un essai sans attendre la suite.
if ( ! os.close() )
Et comme tu le sous-entend, il s'est repris par la suite.
Au fait, pourquoi std::basic_fstream<>::close() ne retourne-t-elle pas ce que lui retourne std::basic_filebuf<>::close() ? Voire une référence vers le flux, convertible en booléen. De manière à pouvoir écrire le test ci-dessus. Y a-t-il une motivation derrière cette décision ?
Heu... j'espère que ce n'est pas à moi que tu poses cette question.
-- Oxidor Trucidel
drkm
"oxidor trucidel" writes:
Heu... j'espère que ce n'est pas à moi que tu poses cette question.
Ben, si, entre autres. Enfin, à qui veut y répondre.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
"oxidor trucidel" <oxidor@uf.net> writes:
Heu... j'espère que ce n'est pas à moi que tu poses cette question.
Ben, si, entre autres. Enfin, à qui veut y répondre.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Heu... j'espère que ce n'est pas à moi que tu poses cette question.
Ben, si, entre autres. Enfin, à qui veut y répondre.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
James Kanze
"oxidor trucidel" writes:
|> J'ai essayé le truc de Loic avec ofstream sans fichier de |> sauvegarde, j'obtient plusieurs erreurs à la ligne if (!os(close))
|> Du coup, je prends mon petit lexique c++ au chapitre ofstream et je |> lis "comportement par défaut: s'il ne trouve pas le fichier que vous |> voulez ouvrir, il en crée un".
Si tu ouvres le fichier en lecture seulement, ce qui est le défaut pour un ifstream, il ne doit pas être créer.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
"oxidor trucidel" <oxidor@uf.net> writes:
|> J'ai essayé le truc de Loic avec ofstream sans fichier de
|> sauvegarde, j'obtient plusieurs erreurs à la ligne if (!os(close))
|> Du coup, je prends mon petit lexique c++ au chapitre ofstream et je
|> lis "comportement par défaut: s'il ne trouve pas le fichier que vous
|> voulez ouvrir, il en crée un".
Si tu ouvres le fichier en lecture seulement, ce qui est le défaut pour
un ifstream, il ne doit pas être créer.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> J'ai essayé le truc de Loic avec ofstream sans fichier de |> sauvegarde, j'obtient plusieurs erreurs à la ligne if (!os(close))
|> Du coup, je prends mon petit lexique c++ au chapitre ofstream et je |> lis "comportement par défaut: s'il ne trouve pas le fichier que vous |> voulez ouvrir, il en crée un".
Si tu ouvres le fichier en lecture seulement, ce qui est le défaut pour un ifstream, il ne doit pas être créer.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
drkm writes:
|> "oxidor trucidel" writes:
|> > j'ai eu l'idée de |> > faire un fichier "perso.txt" qui contient uniquement la liste des |> > fichiers .pj
|> AMHA, c'est une bonne solution.
À vrai dire, je préfère sa première solution : un répertoire qu'il lit.
Sinon, il y a aussi la solution classique de mettre tout dans un seul fichier, qui est divisé en sections.
|> Le fichier gagnerait cependant à être renommé. Et un petit script |> Shell ou Perl pourrait être intéressant pour vérifier la cohérence |> de ces listes de fichiers avec l'état effectif du FS, ou |> reconstruire facilement ces listes de fichiers.
Justement. Tu as dupliqué l'information ; tu gagnes donc le problème de s'en assurer la cohérence.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
drkm <usenet.fclcxx@fgeorges.org> writes:
|> "oxidor trucidel" <oxidor@uf.net> writes:
|> > j'ai eu l'idée de
|> > faire un fichier "perso.txt" qui contient uniquement la liste des
|> > fichiers .pj
|> AMHA, c'est une bonne solution.
À vrai dire, je préfère sa première solution : un répertoire qu'il lit.
Sinon, il y a aussi la solution classique de mettre tout dans un seul
fichier, qui est divisé en sections.
|> Le fichier gagnerait cependant à être renommé. Et un petit script
|> Shell ou Perl pourrait être intéressant pour vérifier la cohérence
|> de ces listes de fichiers avec l'état effectif du FS, ou
|> reconstruire facilement ces listes de fichiers.
Justement. Tu as dupliqué l'information ; tu gagnes donc le problème de
s'en assurer la cohérence.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > j'ai eu l'idée de |> > faire un fichier "perso.txt" qui contient uniquement la liste des |> > fichiers .pj
|> AMHA, c'est une bonne solution.
À vrai dire, je préfère sa première solution : un répertoire qu'il lit.
Sinon, il y a aussi la solution classique de mettre tout dans un seul fichier, qui est divisé en sections.
|> Le fichier gagnerait cependant à être renommé. Et un petit script |> Shell ou Perl pourrait être intéressant pour vérifier la cohérence |> de ces listes de fichiers avec l'état effectif du FS, ou |> reconstruire facilement ces listes de fichiers.
Justement. Tu as dupliqué l'information ; tu gagnes donc le problème de s'en assurer la cohérence.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
drkm
James Kanze writes:
Justement. Tu as dupliqué l'information ; tu gagnes donc le problème de s'en assurer la cohérence.
En effet.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
James Kanze <kanze@gabi-soft.fr> writes:
Justement. Tu as dupliqué l'information ; tu gagnes donc le problème de
s'en assurer la cohérence.
En effet.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Justement. Tu as dupliqué l'information ; tu gagnes donc le problème de s'en assurer la cohérence.
En effet.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Fabien LE LEZ
On 15 Aug 2004 21:51:15 +0200, James Kanze :
Sinon, il y a aussi la solution classique de mettre tout dans un seul fichier, qui est divisé en sections.
Avec les problèmes que ça pose, notamment quand on cherche à modifier en même temps deux fichiers (et donc ici, deux sections du même fichier). En tout cas, je suis bien content qu'en PHP opendir() soit standard -- ça m'évite bien des soucis sur les sites web, où plusieurs instances du même script peuvent tourner en même temps sans que j'aie le moindre contrôle.
On 15 Aug 2004 21:51:15 +0200, James Kanze <kanze@gabi-soft.fr>:
Sinon, il y a aussi la solution classique de mettre tout dans un seul
fichier, qui est divisé en sections.
Avec les problèmes que ça pose, notamment quand on cherche à modifier
en même temps deux fichiers (et donc ici, deux sections du même
fichier).
En tout cas, je suis bien content qu'en PHP opendir() soit standard --
ça m'évite bien des soucis sur les sites web, où plusieurs instances
du même script peuvent tourner en même temps sans que j'aie le moindre
contrôle.
Sinon, il y a aussi la solution classique de mettre tout dans un seul fichier, qui est divisé en sections.
Avec les problèmes que ça pose, notamment quand on cherche à modifier en même temps deux fichiers (et donc ici, deux sections du même fichier). En tout cas, je suis bien content qu'en PHP opendir() soit standard -- ça m'évite bien des soucis sur les sites web, où plusieurs instances du même script peuvent tourner en même temps sans que j'aie le moindre contrôle.
