Discussion :

[Seabirds]

Salut à toutes et à tous !

Une question que j'ai dans la tête mais qui ne semble pas avoir été traitée ici :
doit on appeller manuellement la méthode close() sur un objet ftsream ou bien laisser le destructeur s'en occuper ?
Ici sur stackoverflow, certains semblent dire que le destructeur fait ça très bien.
Mais ici dans la FAQ les méthode close sont dans certains cas appelées explicitement...

Qu'en pensez-vous ?

[Matt_Houston]

http://en.cppreference.com/w/cpp/io/basic_fstream/close

This function is called by the destructor of basic_fstream when the stream object goes out of scope and is not usually invoked directly.

Tu appelles close quand tu veux conserver le handle pour une réutilisation ultérieure. C'est plutôt rare.

[Seabirds]

http://en.cppreference.com/w/cpp/io/basic_fstream/close
Tu appelles close quand tu veux conserver le handle pour une réutilisation ultérieure. C'est plutôt rare.

Merci de ta réponse Mais si on en a besoin ultérieurement, pourquoi ne pas le laisser ouvert ? Au cas où on devrait/pourrait avoir un deuxième fstream sur la même ressource ?
Aurais-tu un petit exemple d'un cas d'utilisation où il vaut mieux appeler close ? (désolé, mon esprit de noob s'adapte mal aux généralités ).

[Bousk]

- garder un fichier ouvert est pas forcément top ou possible
- si tu veux ouvrir un autre fichier

[Pyramidev]

Salut,

Pour la documentation, de manière générale, il faut privilégier en.cppreference.com qui est souvent plus précis que www.cplusplus.com

Dans la page de std::basic_fstream ( http://en.cppreference.com/w/cpp/io/basic_fstream ), on lit clairement : « (destructor) [virtual] (implicitly declared) destructs the basic_fstream and the associated buffer, closes the file »

Dans la page http://www.cplusplus.com/reference/f...basic_fstream/ , il n'y a pas de mention directe du destructeur. Par contre, la doc précise que std::basic_fstream encapsule un std::basic_filebuf dont la doc du destructeur ( http://www.cplusplus.com/reference/f...basic_filebuf/ ) précise : « Before being destroyed, member function close is automatically called. »
Dans cet exemple, on finit par avoir l'info aussi, mais plus difficilement.

Mais si on en a besoin ultérieurement, pourquoi ne pas le laisser ouvert ? Au cas où on devrait/pourrait avoir un deuxième fstream sur la même ressource ?
Aurais-tu un petit exemple d'un cas d'utilisation où il vaut mieux appeler close ? (désolé, mon esprit de noob s'adapte mal aux généralités ).

Personnellement, un cas où j'ai dû appeler explicitement close(), c'est quand je voulais envoyer un fichier de log par mail. Pour que ça fonctionne, j'ai dû fermer le fichier, puis appeler une fonction qui l'envoie par mail, puis le rouvrir.
Dans ce contexte, il est plus simple de travailler avec le même objet de flux que d'en détruire un puis en créer un autre.
Un autre cas est celui où j'ai dû changer le chemin d'un fichier de log. J'ai fermé le fichier, puis je l'ai coupé-collé, puis je l'ai rouvert. La raison est que mon application avait besoin de loguer très tôt, bien avant l'étape où mon application savait quelle devait être l'adresse finale du fichier de log.

A part ça, la différence entre close() et le destructeur de std::basic_fstream, c'est que close() peut lancer une exception que tu peux gérer comme tu veux, par exemple en écrivant dans un fichier de log un message d'erreur. Par contre, le destructeur de std::basic_filebuf (appelé par celui de std::basic_fstream) intercepte les éventuelles exceptions lancées par close() et ne les propage pas.

[Seabirds]

Super réponses, merci tout le monde !

[koala01]

Salut,

De manière générale, la manipulation de fichiers va passer par une foule assez importante de ce qu'il convient d'appeler des appels système : des instructions spécifiques au système d'exploitation sur lequel l'application sera exécutée.

Le gros problème, c'est donc de savoir... comment le système d'exploitation pourra bien réagir face, par exemple, à toute tentative d'ouverture d'un fichier qu'il sait être déjà ouvert (et n'avoir pas été fermé) "par ailleurs".

La plupart des systèmes vont placer ce que nous pourrions appeler des "verrous" (locks) sur les fichiers ouverts en faisant en sorte d'empêcher de manière systématique l'ouverture d'un fichier qui aurait déjà été marqué comme ouvert (et non refermé). Même s'il se peut que le système d'exploitation renonce à le faire sur un fichier qui serait ouvert en "lecture seule" (et encore, rien n'est moins sur), il y a très peu de chance qu'il le fasse sur un fichier ouvert "en écriture", vu que chaque écriture dans le fichier va avoir un grand nombre de conséquences "matérielles" (dont, entre autres, au niveau du "système de fichiers" utilisé par le support sur lequel se trouve le fichier).

A la lueur de ces explications, tu vas sans doute te rendre compte que, bien que tu puisse effectivement envisager de garder un fichier ouvert "aussi longtemps que tu en auras besoin", c'est une décision qui risque d'avoir énormément d'impact non seulement sur ta propre application, mais aussi... sur l'ensemble de ton système d'exploitation; et principalement sur... les applications qui, pour une raison ou une autre, devraient avoir accès au même fichier.

Il serait sans doute vain de t'interdire de garder un fichier ouvert dans ton application. Après tout, tu gardes ton libre arbitre, et ma propre liberté de choix s'arrête là où commence la tienne . Mais, vu que tu poses la question, je suis en droit de te présenter mon point de vue sur le sujet : c'est généralement une aussi mauvaise idée que celle qui pourrait te traverser l'esprit de diriger un fusil chargé sur ton pied et de presser la détente : tu peux le faire, mais tu sais ce que tu risques à le faire

[Seabirds]

Il serait sans doute vain de t'interdire de garder un fichier ouvert dans ton application.

Dans ma petite tête de débutant, un conseil validé par développez.com a valeur d'interdiction sacrée
J'ai appris à appliquer vos conseils avec confiance, même si c'est parfois sans trop bien les comprendre, auquel cas je sais que ça prendra son sens plus tard

Merci de ta réponse en tout cas !

[ternel]

Il est bien éduqué, celui-là…

N'hésite surtout pas à demander plus d'explication quand tu ne comprends pas bien.

[Luc Hermitte]

Un autre angle sur le sujet. (NB j'ai aussi croisé le cas anecdotique du logger où il est préférable de fermer pour ouvrir un nouveau fichier, mais je vais m'étendre sur un autre cas d'utilisation)

En ce qui me concerne, la question de garder un fichier ouvert ne se pose pas car mes utilisations de fichiers sont précisément cadrées dans des portées, et donc mes fichiers sont fermés lorsque la variable fstream est détruite. Quand je le peux, je fuis comme la peste les pointeurs sur des flux et autres listes dont la portée peut transcender la fonction qui voit l'ouverture et le traitement du fichier. SRP oblige, je réduis la portée d'utilisation du fichier/flux au strict minimum nécessaire.

Dans mon cas, on peut se demander à quoi fstream::close peut bien servir. Il y a un cas: si je dois savoir si la fermeture a échoué. Typiquement, si j'écris sur un disque distant qui se déconnecte/un disque qui flambe/une clé arrachée/etc avant la fermeture du fichier, et que je veux le savoir pour réagir en conséquence. Dans ce cas là, je ferme explicitement pour analyser l'état du flux après l'appel à fstream::close -- qui ne lance pas d'exception par défaut.
Honnêtement, dans les applications que je développe je n'ai jamais eu à me poser cette question, pourtant légitime sur des systèmes critiques. Je me contente du RAII et sa limitation qui ne me permet pas de savoir si la restitution de la ressource a échoué.