Différence entre ios :: app et ios :: ate
Duplicata possible:
Gestion des fichiers C++: Différence entre ios: app et ios: ate?
Quelle est la différence entre ces deux modes d'ouverture de fichier?
ios: ate définit la position du pointeur get/put à la fin du fichier => la lecture/l'écriture commencera à partir de la fin, mais en quoi est-ce différent de ios :: app, qui ouvre à nouveau un fichier en mode ajout ... mais quand J'ai créé un ofstream et l'ai ouvert en mode ios: app, le pointeur de flux de vente pointe toujours vers le début, comment fonctionne alors l'ajout?
Je comprends également que ifstream, ofstream et fstream sont des classes de haut niveau pour gérer le tampon de flux sous-jacent. Cela signifie-t-il donc que même en mode iOS: application, je peux lire les données d'un fichier?
app vient de 'append' - toutes les sorties seront ajoutées (ajoutées) à la fin du fichier. En d'autres termes, vous ne pouvez écrire nulle part ailleurs dans le fichier, mais à la fin.
ate vient de "à la fin" - il définit la position du flux à la fin du fichier lorsque vous l'ouvrez, mais vous êtes libre de le déplacer (rechercher) et d'écrire où bon vous semble.
ate vous positionne simplement à la fin du fichier après ouverture, et rien d'autre. Ce n'est pas très utile sur un ofstream, du moins sans autres drapeaux, puisque le fichier sera de toute façon tronqué, donc le début est la fin. (Pour éviter la troncature et pouvoir toujours écrire n'importe où dans le fichier, vous devez ou dans ios::in également, même si vous n'allez pas lire.)
app empêche la troncature d'un fichier existant et fait passer chaque écriture à la fin du fichier. Atomiquement, si possible; si d'autres processus écrivent dans le même fichier, votre écriture doit toujours se terminer. Notez cependant que cela fait référence à l'écriture réelle au niveau du système. Cependant, si vous écrivez des lignes inférieures à la taille de la mémoire tampon et que vous terminez chaque ligne par std::endl, vous pouvez compter sur l'ajout atomique de chaque ligne, indépendamment de ce que d'autres processus pourraient faire avec le fichier. Pour être efficace, vous voudrez probablement utiliser pubsetbuf sur le filebuf également, pour garantir une taille de tampon minimale.
Dans la pratique, je ne pense pas avoir jamais utilisé l'un d'eux, ni les avoir trouvés d'aucune utilité. Les problèmes de mise en mémoire tampon avec app, en particulier, m'ont généralement conduit à écrire ma propre streambuf, avec une mise en mémoire tampon illimitée conceptuellement (un std::vector<char> en tant que tampon), qui ouvre le fichier système sous-jacent avec l'équivalent de app, mais ne garantit l'écriture que lorsqu'il est explicitement vidé (comme avec `std :: endl).
Si vous regardez par exemple cette référence , vous verrez:
app seek to the end of stream before each write
et
ate seek to the end of stream immediately after open
Cela signifie que ios::app n'écrit qu'à la fin, mais que ios::ate lit et écrit à la fin par défaut. Cependant, avec ios::ate vous pouvez rechercher librement dans le fichier, mais avec ios::app vous écrivez toujours à la fin, quelle que soit la position que vous définissez pour le pointeur d'écriture.