11 votes

Quelles sont les garanties concernant les lectures et écritures entrelacées ?

Lorsque l'on travaille avec un C++ std::iostream (par exemple, std::fstream o std::stringstream La norme garantit-elle quoi que ce soit quant aux relations entre les lectures et les écritures effectuées sur le même flux ? En d'autres termes, est-il nécessairement vrai que si j'écris des données dans un fichier std::fstream puis essayer de lire des données à partir de ce flux, je devrais voir les données que j'ai écrites ? Et dans le cas d'un std::stringstream ? A titre d'exemple, le fonctionnement est-il garanti ?

std::stringstream myStream;
myStream << "137 Hello 2.71828";

int myInt;
std::string myString;
double myDouble;

myStream >> myInt >> myString >> myDouble; // Parse as expected?

Ou qu'en est-il de cette affaire ?

std::fstream myStream("some-file.txt", ios::in | ios::out);
myStream << "137 Hello 2.71828";

int myInt;
std::string myString;
double myDouble;

myStream >> myInt >> myString >> myDouble; // Parse as expected?

Je pose cette question parce que j'ai récemment développé une classe de flux en réseau dans laquelle les lectures et les écritures ne s'influencent pas les unes les autres (puisque les lectures tirent du réseau et les écritures envoient à travers le réseau). En d'autres termes, l'écriture

myNetworkStream << "Hi there!" << endl;

écrit sur le réseau, tandis que

myNetworkStream >> myValue;

lit le réseau. Je ne suis pas sûr que ce comportement soit cohérent avec le contrat général pour les flux. Si je devais deviner, l'une des trois possibilités suivantes s'applique probablement :

  1. En iostream Le contrat ne dit rien sur les lectures et les écritures entrelacées, ni sur l'utilisation de la technologie de l'information.
  2. En général, les iostream ne dit rien sur les lectures et écritures entrelacées, mais il y a des dispositions spécifiques dans la spécification qui régissent la façon dont les types standard tels que fstream y stringstream travail, ou
  3. En iostream Le contrat dit quelque chose à propos des lectures et écritures entrelacées qui fait que ma classe de flux réseau est violée.

J'ai une copie de la spécification, mais la section sur les flux est tellement dense et énigmatique qu'il est pratiquement impossible de la suivre. Si quelqu'un pouvait clarifier exactement comment iostream sont censés se comporter lorsque l'on mélange des lectures et des écritures, j'apprécierais beaucoup.

10voto

DevSolar Points 18897

Je ne suis pas sûr du chapitre et du verset de la C++ (que je n'ai pas sous la main pour vérifier), mais je connais très bien la norme C sur le sujet (que j'ai d'ailleurs faire ont autour d'eux).

La norme C99 stipule qu'un flux peut être ouvert en mode lecture, écriture ou "mise à jour". Seul ce dernier mode permet de lire et d'écrire dans le même flux, mais (citation) :

...l'output ne doit pas être suivi directement par l'input sans un appel intermédiaire à l'utilisateur. sans un appel intermédiaire à la fonction fflush ou à une fonction de positionnement de fichier ( fseek , fsetpos ou rewind ), et l'entrée ne doit pas être directement suivie d'une sortie sans qu'il y ait un calage intermédiaire. sans appel intermédiaire à une fonction de positionnement de fichier, à moins que l'opération d'entrée ne rencontre une fin de fichier. une fin de fichier.

Je suppose que la norme C++ dit quelque chose de similaire quelque part : Vous devez vider ou repositionner le flux avant d'inverser le sens de lecture ou d'écriture.

Edita: Il existe en effet deux pointeurs distincts, qui peuvent être interrogés à l'aide de la fonction basic_istream::tellg y basic_ostream::tellp . Toutefois, j'ai trouvé une mention de la possibilité que les deux pas pointant à la même position dans le flux uniquement en relation avec stringstream pas pour fstream . Si l'on tient compte de la déclaration ci-dessus, c'est logique. Je ne peux cependant pas vous indiquer le chapitre et le verset de la norme, désolé.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X