Question bete lecture de fichier

Dans la suite de ma conversion du C au C++ je me pose une question sur la lecture de fichier. typiquement si je fais une lecture en boucle du style

Code:

---

1 2 3 4 5 6 7

string nom_dossier; ifstream file_info("liste_dossier.txt");   while(file_info>>nom_dossier) { cout<<nom_dossier<<endl; }

---

pratiquement il sort de la boucle lorsqu'il arrive à la fin du fichier "liste_dossier.txt"
mais theoriquement ifstream derive de istream et herite de l'operateur istream::operator>>
Dans la doc je vois que cet operateur retourne (*this) or je comprend pas que si (*this) est systematiquement retourné on sorte du while. Je vois peut etre trop les choses du style C mais en générale la sortie de cette boucle se fait pour des valeurs nulle? ce qui ne devrait pas etre le cas de (*this). On est ce que je peche dans la comprehension du buisiness?
Merci pour vos lumieres
;)

justement (*this), c-à-d le ifstream, possède un opérateur d'évaluation qui l'évalue en VRAI s'il reste des choses à extraire ou FALSE sinon ;).

EDIT : en fait j'ai vérifié sur cppreference.com, l'objet ifstream renvoie false pour toute erreur (par exemple tentative de lecture à la fin du fichier, mais aussi erreur d'ouverture, etc...

ok merci j'avais pas regardé sur cppreference mais sur cplusplus.com :)
ça me rassure donc!

il me semble bien que c'est celui-là : http://cplusplus.com/reference/iostr...eratornot.html

:)

oui mais dans mon cas je ne fais pas appel à cet operateur, l'évalution se fait directement dans le while avec le retour en false !! d'ailleur tu aurais le lien sur cppreference pour le retour de la valeur false?

c'est quant meme un peu moins pratique si on veut ecrire des données numériques :? car pour ecrire un truc du genre 2.12345678.e+04 avec les espacement pour en ecrire à la volée, j'ai lutté. Mais bon, faut dire que j'ai encore les automatismes du C...

ça me parait toujours pas clair... j'arrive pas à mettre la main sur un endroit (doc) où ça explique la sorite de la boucle while :?

La :faq: ?

Je pense que la question n'est pas du tout bete :
Lorsque on evalue ifstream dans un contexte boolean il renvoie false lorsqu'un de ces etats est vraie (badbit,eofbit,failbit)

http://cpp.developpez.com/faq/cpp/?p...IERS_test_open

ah merci flyweight c'est exactement la reponse qu'il me fallait !!!
je pensait pas trouver la reponse à ma question dans la FAQ... la prochaine fois je ferai dabord un trou par là

Questions qui vont avec, et qui m'enlevera certains doutes : qui décide de la conversion, c'est bien l'operator! ? Ou un autre ? ça dépend de l'implémentation ? Si oui pourquoi cpluscplus.com ne mentionne que operator! ?

ben visiblement c'est le compilateur qui fait une conversion implicite en void* pour le caster en pointer

par contre il y a un truc que je capte pas. Je souhaite ecrire à la suite des résultats stockés dans un tableau de double par ex. je fais en boucle for pour tout ecrire, le probleme c'est pour le formattage je doit à chaque fois (dans la boucle) specifier le width(size). Alors que la precision reste.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

ofstream file_out("res.dat"); ... file_out.setf(ios::scientific); // OK file_out.precision(10); // OK   for(int i=0;i<nb_elements;++i) { file_out.width(20); // Je dois le mettre ici et pas en haut file_out<<tab[i]; }

---

Si je le met width avant la boucle for, il me sort le premier resultat avec ce width puis colle les autres.
Est ce qu'il y a un moyen de definir une fois pour toute la taille width?

EDIT: je viens de voir les iomanip, à voir si c'est une soolution, mais ça reviendrai au meme (en plus classe)

Code:

---

cout<<setw(20)<<tab[i];

---

Citation:

---

qui décide de la conversion, c'est bien l'operator! ? Ou un autre ?

---

Dans le cas où l'on écrit if (!file), l'operateur ! est directement appellé par le programmeur donc il est utilisé.
Mais dans le cas de while(file_info>>nom_dossier), l'opérateur ! n'entre pas du tout en jeu. Ce n'est pas un opérateur de conversion implicite attention.

Je ne suis pas certain de ce que je vais dire, donc ne prennez pas mes paroles pour acquises, mais à mon avis l'appel à while() est traité par le compilateur comme une fonction normale prennant un seul paramètre booléen.

A partir de là ce sont les mêmes règles qui s'appliquent aux fonctions c-a-d :

Citation:

---

Envoyé par C++ Templates : The Complete Guide

At a very high level, a call to a named function can be processed in the following way:

• The name is looked up to form an initial overload set.
• If necessary, this set is tweaked in various ways (for example, template deduction occurs).
  
• Any candidate that doesn't match the call at all (even after considering implicit conversions and default arguments) is eliminated from the overload set. This results in a set of so-called viable function candidates.
  
• Overload resolution is performed to find a best candidate. If there is one, it is selected; otherwise, the call is ambiguous.
  
• The selected candidate is checked. For example, if it is an inaccessible private member, a diagnostic is issued.

---

La formation d'un set est rapide pour while car il n'existe normalement pas de surcharge.
Le deuxième point n'entre pas en jeu pour while().
C'est donc la troisième étape qui nous intéresse, et là, il y a aussi des règles :

Citation:

---

(from best to worst):

• Perfect match. The parameter has the type of the expression, or it has a type that is a reference to the type of the expression (possibly with added const and/or volatile qualifiers).
  
• Match with minor adjustments. This includes, for example, the decay of an array variable to a pointer to its first element, or the addition of const to match an argument of type int** to a parameter of type int const* const*.
  
• Match with promotion. Promotion is a kind of implicit conversion that includes the conversion of small integral types (such as bool, char, short, and sometimes enumerations) to int, unsigned int, long or unsigned long, and the conversion of float to double.
  
• Match with standard conversions only. This includes any sort of standard conversion (such as int to float) but excludes the implicit call to a conversion operator or a converting constructor.
  
• Match with user-defined conversions. This allows any kind of implicit conversion.
  
• Match with ellipsis. An ellipsis parameter can match almost any type (but non-POD class types result in undefined behavior).

---

Ici, on réussi à satisfaire l'avant dernier point avec l'operateur void* grâce à ces règles là :

Citation:

---

Pointers and pointers to members undergo various special standard conversions, including

• Conversions to type bool
  
• Conversions from an arbitrary pointer type to void*
  
• Derived-to-base conversions for pointers
  
• Base-to-derived conversions for pointers to members

---

pfiou, on y est.

Mais si ifstream définissait directement un opérateur de conversion implicite vers bool, c'est ce dernier qui serait utilisé car le chemin de conversion serait plus court : la dernière étape (conversion void* -> bool) est en moins.

Les options de stream comme (fill character,justification left/right...) persistent mais le width est Réinitialisé a 0 apres chaque operation output.:)
(C'est plus pratique dans la plupart des cas)