Bonjour ! J'aimerais savoir ce qu'est cin.good et cin.eof
Merci d'avance
Version imprimable
Bonjour ! J'aimerais savoir ce qu'est cin.good et cin.eof
Merci d'avance
Pour ce genre de question le plus rapide est de consulter ta doc de référence préférée ; tu en trouveras tout un tas dans la FAQ si tu n'en connais pas.
http://c.developpez.com/faq/cpp/?pag...ERALITE_cppdoc
Salut,
De manière générale, cin est un gestionnaire de flux d'entrée, tout comme pourrait l'etre les autres i*stream.
A ce titre, il dispose de plusieurs "drapeaux" (flags) qui permettent de se faire une idée de l'état du flux sur lequel il travaille.
Ainsi, on trouve, dans la classe ios_base, les drapeaux suivants, dont cin dispose:
- badbit: indique que le flux est corrompu
- eofbit:indique que la fin du fichier est atteinte
- failbit: indique que l'opération suivante échouera
- goodbit indique que l'opération suivante a des chances de réussir
Evidemment, failbit est intimement lié à badbit et à eofbit, et goodbit ne peut pas etre vrai en meme temps que failbit ;)
et, dans les gestionnaire de flux, on trouve les méthodes
- rdstate(): renvoye les quatre bits sous la forme dun ios_base::iostate
- eof(): renvoie l'état de eofbit (booléen)
- fail(): renvoie l'état de failbit (booléen)
- bad(): renvoie l'état de badbit (booléen)
- good(): renvoie l'état de good (booléen)
Cela signifie que tu peux envisager des codes ressemblant à
qui réagira, en définitive, de la meme manière queCode:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19 if( cin.eof()) { // ici, la fin du flux est atteinte } if(cin.bad()) { // ici, le flux est corrompu (il arrive qu'il y ai " // des souris" dans les cables ;)) } if(cin.fail()) { // ca ne sert à rien d'essayer d'encore accéder au flux // soit parce que sa fin est atteinte, soit parce qu'il est corrompu } if(cin.good()) { // *normalement* on peut tenter d'accéder au flux }
A noter, enfin que les codesCode:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23 //récupération de l'état du flux ios_base::isotate etat=cin.rdstate(); // on vérifie si badbit est à 1 avec un ou binaire if(etat & ios_base::badbit) { //le flux est corrompu } //meme chose avec failbit if(etat & ios_base::failbit) { //équivalent à cin.fail() } // toujours pareil avec eofbit if(etat & ios_base::eofbit) { //correspond à cin.eof() } // et pareil avec goodbit if(etat & ios_base::goodbit) { // correspond à cin.good() }
etCode:
1
2
3
4
5 while(cin.good()==true) { ... }
réagiront également de la meme manière ;)Code:
1
2
3
4
5 while(cin.fail()!=true) { ... }
je dirais plutot a ete atteinte. En fait, il indique que l'operation suivante echouera a cause de la fin du fichier.Citation:
Envoyé par koala01
Non. Il indique qu'une operation anterieure a echoue.Citation:
- failbit: indique que l'opération suivante échouera
Non. Il n'y a pas reellement de goodbit independant des autres. C'est une constante a utiliser quand les trois autres ne sont pas de mise.Citation:
- goodbit indique que l'opération suivante a des chances de réussir
Non. fail() renvoie (rdstate() & (failbit | badbit)) != 0Citation:
- rdstate(): renvoye les quatre bits sous la forme dun ios_base::iostate
- eof(): renvoie l'état de eofbit (booléen)
- fail(): renvoie l'état de failbit (booléen)
good renvoie rdstate() == 0Citation:
- bad(): renvoie l'état de badbit (booléen)
- good(): renvoie l'état de good (booléen)
Il faut aussi citer les plus utilises: operator void*() qui retourne un pointeur non NULL si !fail() et operator!() qui est un synonyme de fail() mais a l'avantage d'un nom n'induisant pas en erreur.
Je ne suis pas sur de ce que tu veux ecrire. Le code que tu donnes est generalement un erreur. La technique en C et en C++, c'est de tenter l'operation d'IO et d'ensuite tester si elle a reussit. Generalement d'ailleurs avec operator void* (c'est pas toujours tres clair mais c'est la methode idiomatique, ce qui fait que les alternatives sont encore moins claires parce qu'on se demande si elles sont correctes ou pas; generalement elles ne le sont pas). Par exemple:Citation:
A noter, enfin que les codes
etCode:
1
2
3
4
5 while(cin.good()==true) { ... }
réagiront également de la meme manière ;)Code:
1
2
3
4
5 while(cin.fail()!=true) { ... }
On peut utiliser ensuite eof(), fail() et bad() pour tenter de discerner s'il y a probleme, ou simplement la fin normale du fichier mais le degre de descernement est relativement faible (par exemple avec eof() retournant true on sait que la fin de fichier a ete atteinte, mais on ne sait pas si l'IO a echoue a cause de cela ou d'une autre raison si la methode utilisee pour faire les IO permet une autre raison).Code:
1
2
3 while (std::getline(cin, line)) { ... }
Merci pour votre eclair
Et pourtant, le stroutrup écrit (page 685: chapitre 21.3.3: état d'un flux)Citation:
Non. Il indique qu'une operation anterieure a echoue.Citation:
- failbit: indique que l'opération suivante échouera
(et un peu plus loin, le meme commentaire concernant failbit)Code:
1
2
3
4 (...) bool fail() const; //l'opération suivante échouera (...)
Si l'on a, de fait, de fortes chances qu'une opération échouera si la précédente a échoué, stroutrup ne parle pas du tout de l'opération précédente...
De plus, dans les pages qui ont trait au flux, il utilise à plusieurs reprises les morceaux de code tels que je les ai montrés (pas tous ensemble, je te l'accorde)
Je ne dis absolument pas que je trouve les codes proposés faciles à utiliser, mais... qu'ils sont sensés etre corrects...
Je sais aussi que stroutrup a été attaqué par d'autres pointures, mais... dans le cas qui nous intéresse, a-t-il tord ou raison :question:
Version ? Edition ? Révision ? (c'est pas corrigé dans les errata?)Citation:
Envoyé par koala01
(Je n'ai pas vérifié s'il y avait eu un "patch" dans la révision de 2001.)Citation:
Envoyé par ISOIEC14882-1998, §27.4.2.1.3, Table 85, p 608
Soit, c'est bien positioné après avoir tenté d'injecter ou d'extraire. En fait, comment pourrait-il en être autrement ? Et évidemment, la prochaine opération foirera, vu que la dernière a déjà été plantée.
Evidemment avec les versions qui se succedent...
Celle dont je dispose est la Quatrième édition (version francaise) achevé d'imprimé le 16/02/2001, sans errata...
Dans cette édition, on lit:
Suis l'exemple de code suivant (apres avoir indiqué la partie de la classe ios_base qui contient les flags)Citation:
Envoyé par stroutrup
Je sais que la version anglaise en est à la cinquième édition, mais ici, il présente l'état fail() comme étant le fait que l'action suivante échoueras (ce qui, de fait, est logique si l'action précédente a échoué)... non comme le fait que l'action précédente a échoué ;)Code:
1
2
3
4
5
6
7
8
9
10
11
12 void f() { ios_base::iostate s=cin.rdstate(); //retoune un ensemble de bits iostate if(s& ios_base::badbit){ //les caractères de cin sont peut etre perdus } //... cin.setstate(ios_base::failbit); //... }
Maintenant, il n'est pas du tout exclu qu'il se soit trompé dans cette édition ;) (apres tout, l'erreur est humaine ;))
Et, effectivement, il semble bien plus logique que failbit (et les autres) représentent l'état apres la dernière action effectuée, et non "en prévision de l'action suivante" :P
Non, non. Même la version française ne devrait pas avoir dépassé la 3e ed -- comment s'y retouver après. :aie: http://www.research.att.com/~bs/3rd.html
Par contre, la VF a subit une révision technique conséquence (j'ai envie de dire majeure) par Michel Michaud. Je ne sais pas si le nom de Michel apparait en clair dans le bouquin, ou pas.
Si je me souviens bien, il est à l'origine de l'introduction d'un lexique donnant diverses traductions des termes consacrés au C++.
Quant à "f()", j'ai du mal à lui faire dire quoique ce soit avec les "...".
Mais effectivement, sa VO semble proche (et de bien parler de "next operation will fail"), les errata n'ayant corrigé qu'un autre détail sur lequel on ne pinaillait pas.
Et pourtant, je t'assure que, bien que tapant en aveugle par habitude, j'ai écrit in extenso ce qui se trouvait dans le bouquin (pour information, la version que j'ai, c'est le code ISBN 2-7440-1089-8 "spécial édition" de chez campuspress, et la seule mention qui soit présente quant à la version est cette phrase "pour cette quatrième édition,(...) au dos du livre)
[EDIT]le plus bisard, dans l'histoire, c'est que, ni la couverture, ni le numero ISBN ne correspondent avec ton lien (l'image "C++" sur une vague se trouve au dessu du "le langage C++" chez moi) ...[/EDIT]
Quand j'aurais le temps et mon édition sous la main (ici je n'ai que la deuxième édition), je vérifierai ce qui y est écrit en tenant compte des errata et enverrai éventuellement une suggestion d'errata supplémentaire à BS.
Pas nécessairement. L'état peut ne pas être good() parce que la fin de fichier a été atteinte mais l'opération d'entrée avoir réussit quand même.Citation:
Si l'état est good(), l'opération d'entrée précédente a réussi.
La plupart des entrées qui foirent ont été précédée d'une entrée qui a réussit... Si la plupart des entrées effectuées quand good() est vrai réussissent, c'est parce que la plupart des entrées réussissent.Citation:
Dans ce cas, l'opération suivante devrait également aboutir.
Effectivement, si l'état n'est pas good(), l'entrée suivante échouera. Ne fut-ce que parce que c'est ce que vérifie un sentry.Citation:
Dans le cas contraire, elle échouera.
Je ne suis pas sûr que ce soit vrai. Je me souviens avoir essayé de retrouver cette garantie dans la norme sans y arriver.Citation:
Appliquer une opération d'entrée sur un flux qui ne se trouve pas en état good() est une opération nulle. Si nous tentons de lire une variable v et si l'opération échoue, v restera inchangée (elle est inchangée lorsque v est une variable de l'un des type traités par les fontions membres d'istream ou d'ostream).
C'est la différence entre avoir le failbit et le badbit positionné. Mais fail() teste aussi le badbit.Citation:
La différence entre les états fail() et bad() est assez subtile. Lorsque l'état est fail(), on suppose que le flux n'est pas corrompu et qu'aucun caractère n'a été perdu. Cela n'est pas le cas lorsque l'état est bad()
Il me semble que oui. 2001 me semble vieux pour être la version revue par Michel.Citation:
Envoyé par Luc Hermitte
Relisant la version anglaise, je ne vois rien d'incorrect. Les deux gros points que j'avais:
C'est vrai. Mais il ne faut pas en conclure que si l'etat n'est pas good(), l'operation precedante avait echoue.Citation:
If the state is good() the previous input operation succeeded.
La partie que j'ai citee en gras n'est pas dans le texte que tu as cite (et ne se trouve pas dans le texte francais que j'ai sous la main; au fait Michel Michaud est remercie sur la page de copyright).Citation:
The difference between the states fail() and bad() is subtle. When the state is fail() but not also bad(), it is assumed...
Merci encore pour toutes ces precisions ! ;)