Dois-je fermer manuellement un ifstream?

Je dois manuellement appel close() lorsque j'utilise un std::ifstream?

Par exemple, dans le code:

std::string readContentsOfFile(std::string fileName) {

  std::ifstream file(fileName.c_str());

  if (file.good()) {
      std::stringstream buffer;
      buffer << file.rdbuf();
      file.close();

      return buffer.str();
  }
  throw std::runtime_exception("file not found");
}

Dois-je appeler file.close() manuellement? Ne devrait pas ifstream faire usage de RAII pour la fermeture des fichiers?

InformationsquelleAutor Edison Gustavo Muenz | 2009-04-14

c++ifstream raii

240

PAS

C'est ce que RAII est pour, laisser le destructeur de faire son travail. Il n'y a pas de mal à le fermer manuellement, mais ce n'est pas le C++ façon, c'est de la programmation en C avec des classes.

Si vous voulez fermer le fichier avant la fin d'une fonction, vous pouvez toujours utiliser un imbriquée portée.

Dans la norme (27.8.1.5 modèle de Classe basic_ifstream), ifstream est mise en œuvre avec un basic_filebuf membre détenant le réel descripteur de fichier. Il est considéré comme un membre de sorte que quand un ifstream objet détruit, il appelle le destructeur sur basic_filebuf. Et de la norme (27.8.1.2), que destructeur ferme le fichier:

virtual ˜basic_filebuf();

Effets: Détruit un objet de la classe basic_filebuf<charT,traits>. Appels close().
- +1 je ne savais pas que RAII poignées...je suppose que vous apprenez quelque chose de nouveau tous les jours
- En utilisant une étude de la portée juste pour fermer le fichier est complètement artificielle, si vous voulez dire de la fermer, appeler close() sur celui-ci.
- bon point, c'est une habitude que j'ai ramassé à l'aide d'une serrure de bibliothèque qui n'est pas un non-destructeur de la libération de la méthode. Si il existe une fonction qui vous permet de le fermer, aller de l'avant et de l'utiliser.
- Bien, vous pourriez être en mesure de faire valoir que la limitation de l'objet de la durée de vie de la portée nécessaire signifie que vous n'aurez pas accidentellement accès fermé ifstream. Mais c'est un peu artificiel.
- Je suis tout à fait pour limiter le champ d'application, autant que possible 🙂
- Je suis pour la limitation de la portée, mais l'ajout d'un inutile imbriquée portée est d'avoir des ennuis. Alors responsable (autre que vous) peut mal de la voir comme inutile et supprimer ainsi garder votre fichier ouvert plus longtemps que nécessaire. Peut-être une fonction d'assistance à restreindre le champ d'application serait plus approprié?
- Pourquoi inutilement la portée? Il suffit de laisser le ifstream vivre dans la portée qu'elle a besoin de vivre pour faire le travail, et il sera fermé tout le temps - pas plus tôt ou plus tard que le nécessaire.
- Notez également que basic_filebuf::close() sera toujours rincer. Compter uniquement sur le RAII. Ne laissez pas l'imprévu exceptions modifier le code.
- En C++ imbriqués les étendues sont presque jamais inutile. Ils ont tout à voir avec le comportement du code, en particulier lorsque quelque chose de lancers. Si un futur responsable supprime, il ne sait pas C++ très bien.
- Parfois, vous avez besoin d'appeler close() manuellement pour le traitement des erreurs.
- J'ai eu une mauvaise expérience.Le destructeur ne fermez pas la C flux s'appeler le constructeur de style c FICHIER* de std::ifstream dans VS2013. virtual __CLR_OR_THIS_CALL ~basic_filebuf() _NOEXCEPT { // destroy the object if (_Myfile != 0) _Reset_back(); // revert from _Mychar buffer if (_Closef) close(); }
- vous n'avez pas l'esprit d'une telle fin de commentaire): 1.: Ce constructeur n'est pas standard, doit donc être une MSVC extension. 2.: Ce comportement peut être considéré comme naturel: le Flux ferme de ce qu'il s'ouvre et ne se ferme pas ce qu'il n'a pas ouvert de lui-même...
InformationsquelleAutor Eclipse
65

Avez-vous besoin de fermer le fichier?

PAS de

Si vous fermez le fichier?

Dépend.

Faire vous vous souciez du possible les conditions d'erreur qui pourrait se produire si le fichier ne parvient pas à fermer correctement? Rappelez-vous que des appels à proximité, setstate(failbit) si elle échoue. Le destructeur va appeler close() automatiquement pour vous parce que de RAII mais ne vous laissera pas un moyen de tester l'échouer de peu que l'objet n'existe plus.

InformationsquelleAutor Martin York
14

Je suis d'accord avec @Martin. Si vous écrivez dans le fichier, les données peuvent toujours être assis sur un tampon et pourraient ne pas être écrit dans le fichier jusqu'à ce que close() est appelé. Sans le faire manuellement, vous n'avez aucune idée s'il y a une erreur ou pas. Ne pas signaler les erreurs à l'utilisateur est une très mauvaise pratique.

InformationsquelleAutor Mark Edwards
5

Non, c'est fait automatiquement par le ifstream destructeur. La seule raison pour laquelle vous devriez l'appeler manuellement, c'est parce que la fstream exemple, a une grande portée, par exemple si c'est une variable membre d'une longue vie instance de classe.
- Une autre raison peut être de vérifier le fichier de fermeture des erreurs et éviter de jeter destructeur, si des exceptions sont autorisées avec le cours d'eau.
InformationsquelleAutor Dimitri C.
4

Vous pouvez autoriser le destructeur de faire son travail. Mais comme toute RAII objet, il se peut que l'appel de fermer manuellement peut faire une différence. Par exemple:
```
#include <fstream>

using std::ofstream;

int main() {
  ofstream ofs("hello.txt");
  ofs << "Hello world\n";
  return 0;
}
```
écrit le contenu du fichier. Mais:
```
#include <stdlib.h>

#include <fstream>

using std::ofstream;

int main() {
  ofstream ofs("hello.txt");
  ofs << "Hello world\n";
  exit(0);
}
```
ne l'est pas. Ils sont rares les cas où un processus soudain sorties. Un processus qui se pourrait faire la même.

InformationsquelleAutor ericcurtin

Vous devez vous connecter pour publier un commentaire.