Discussion :

[warubi]

Bonjour ! J'aimerais savoir ce qu'est cin.good et cin.eof
Merci d'avance

[Laurent Gomila]

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

[koala01]

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 à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
}

qui réagira, en définitive, de la meme manière que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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()
}

A noter, enfin que les codes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
while(cin.good()==true)
{
    ...
}

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
while(cin.fail()!=true)
{
    ...
}

réagiront également de la meme manière

[Jean-Marc.Bourguet]

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

je dirais plutot a ete atteinte. En fait, il indique que l'operation suivante echouera a cause de la fin du fichier.

• failbit: indique que l'opération suivante échouera

Non. Il indique qu'une operation anterieure a echoue.

• goodbit indique que l'opération suivante a des chances de réussir

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.

• 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)

Non. fail() renvoie (rdstate() & (failbit | badbit)) != 0

• bad(): renvoie l'état de badbit (booléen)
• good(): renvoie l'état de good (booléen)

good renvoie rdstate() == 0
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.

A noter, enfin que les codes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
while(cin.good()==true)
{
    ...
}

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
while(cin.fail()!=true)
{
    ...
}

réagiront également de la meme manière

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:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
while (std::getline(cin, line)) { 
...
}

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).

[warubi]

Merci pour votre eclair

[koala01]

• failbit: indique que l'opération suivante échouera

Non. Il indique qu'une operation anterieure a echoue.

Et pourtant, le stroutrup écrit (page 685: chapitre 21.3.3: état d'un flux)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
(...)
bool fail() const; //l'opération suivante échouera
(...)

(et un peu plus loin, le meme commentaire concernant failbit)

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

[Luc Hermitte]

Et pourtant, le stroutrup écrit (page 685: chapitre 21.3.3: état d'un flux)

Version ? Edition ? Révision ? (c'est pas corrigé dans les errata?)

failbit indicates that an input operation failed to read the expected characters, or than an output operation failed to generate the desired characters.

(Je n'ai pas vérifié s'il y avait eu un "patch" dans la révision de 2001.)

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.

[koala01]

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:

(...)
Si l'état est good(), l'opération d'entrée précédente a réussi. Dans ce cas, l'opération suivante devrait également aboutir. Dans le cas contraire, elle échouera. 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).

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()

L'état d'un flux est représenté sous la forme d'un ensemble d'indicateurs. Comme la plupart des constantes utilisées pour représenter le comportement des flux, ces indicateurs sont définis dans la classe ios_base de basic_ios(...)

Suis l'exemple de code suivant (apres avoir indiqué la partie de la classe ios_base qui contient les flags)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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);
    //...
}

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é

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"

[Luc Hermitte]

Non, non. Même la version française ne devrait pas avoir dépassé la 3e ed -- comment s'y retouver après. 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.

[koala01]

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]

[Jean-Marc.Bourguet]

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.

Si l'état est good(), l'opération d'entrée précédente a réussi.

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.

Dans ce cas, l'opération suivante devrait également aboutir.

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.

Dans le cas contraire, elle échouera.

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.

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).

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.

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()

C'est la différence entre avoir le failbit et le badbit positionné. Mais fail() teste aussi le badbit.

[Jean-Marc.Bourguet]

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.

Il me semble que oui. 2001 me semble vieux pour être la version revue par Michel.

[Jean-Marc.Bourguet]

Relisant la version anglaise, je ne vois rien d'incorrect. Les deux gros points que j'avais:

If the state is good() the previous input operation succeeded.

C'est vrai. Mais il ne faut pas en conclure que si l'etat n'est pas good(), l'operation precedante avait echoue.

The difference between the states fail() and bad() is subtle. When the state is fail() but not also bad(), it is assumed...

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).

[warubi]

Merci encore pour toutes ces precisions !