comportement de ifstream que je ne comprend pas

Version imprimable

Bonjour,

mon problème c'est que ifstream fonctionne très bien si on lui indique dirèctement le fichier à ouvrir, mais si on lui indique d'abord un fichier non existant, puis un fichier existant, il l'ouvre mais ne le lit pas.

Voilà le code:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
 //On initialise:
    string file_name=""; //le nom du fichier à ouvrir
    ifstream file; //le fichier à ouvrir
 
    if(argv[1])
    {
        file_name=argv[1]; //S'il existe un paramètre, on le donne en nom de fichier à ouvrir
    }
 
    while(1)
    {
        //On tente d'ouvrir le fichier et on vérifie si ça fonctionne
        file.open(file_name.c_str());
        if(file.is_open())
        {
            cout<<endl<<"File opened"<<endl<<endl; //On affiche un  message qui confirme l'ouverture du fichier et on essaie de lire les lignes.
            string line;
            while(getline(file, line))
            {
                cout<<line<<endl;
            }
            file.close();
            break; //On ferme le fichier et on quitte la boucle while
        }
       //Si le fichier n'a pas pu s'ouvrir, on le ferme puis on demande à l'utilisatrice de retaper le nom du fichier, que l'on mettra dans file_name, puis on recommence la boucle.
        else 
        {
            file.close();
            cout<<"Fichier introuvable, veuillez entrer un autre nom de fichier: ";
            cin>>file_name;
        }
    }

Le problème c'est que si on tape dirèctement le nom du fichier en paramètre, tout se passe bien.

Mais si on le rentre par après, le message "File opened" s'affichera, mais pas les lignes.

Merci d'avance à qui me répondra :ccool:

18/09/2009, 22h40
Davidbrcz

Ca sent les flags de l'objet qui sont en position d'erreur.
Pour les tester (puis les remettre à zéro) regarde du coté du type iostate et de tout ce qui est associé (bad(), good(), ...)
18/09/2009, 23h09
Michaeljackfan

Oui merci, c'est bien ça !

Si je test avec "file.is_open && file.good()" je ne rentre pas dans la boucle.
Donc j'ai mis un file.clear() juste après l'avoir fermé et maintenant ça fonctionne très bien, merci encore :ccool:

Au final si tu fais un ifstream par fichier dans ta boucle, ton programme est beaucoup plus simple. ( et pas besoin de .close, de .clear, etc )

ça peut juste ressembler à :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
std::string file_name;
 
if( argc > 1 )
{
    file_name = argv[1];
}
 
bool file_found = false;
while( ! file_found )
{
    std::ifstream file( file_name.c_str() );
 
    if( file )
    {
            std::cout << std::endl << "  ..." << std::endl;
 
            string line;
            while( std::getline( file, line ))
            {
                std::cout << line << std::endl;
            }
 
           file_found = true;
    }
    else
    {
         std::cout << "fichier introuvable etc.. : ";
         std::cin >> file_name;      
    }
}

19/09/2009, 12h35
Michaeljackfan

Ok, mais c'est pas moins performant de chaque fois créer un objet que d'appeler les fonctions d'un objet existant ?
19/09/2009, 14h21
koala01

Salut,

Citation:

Envoyé par Michaeljackfan

Ok, mais c'est pas moins performant de chaque fois créer un objet que d'appeler les fonctions d'un objet existant ?

Dans l'extrême absolu, oui...

En effet, tu as, malgré tout, la construction et la destruction de l'objet qui prenne "un peu de temps" à chaque fois.

Mais il faut rester également réaliste: pour observer un réel déclin des performances (comprend: pour que les performances déclinent à un point tel que tu soit capable d'observer une différence), il faudrait en arriver à une boucle devant s'exécuter plusieurs (dizaines de) milliers (pour ne pas dire des millions) de fois...

Et je ne connais personne qui aura le courage d'introduire "a mano" une telle quantité de fichiers à tester ;)

Même en utilisant les pipes et autres techniques de sérialisation d'instruction, tu garde quand même un peu de marge :D

De plus, on peut réellement estimer que la gestion même des fichiers représente un risque de goulot d'étranglement bien plus important que le seul fait d'effectivement créer et détruire une variable temporaire.

N'oublie jamais:

Citation:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

Autrement dit, avant de t'inquiéter d'un problème qui ne te coutera que "quelques fréquences d'horloges", inquiète toi de l'efficacité de tes algorithmes, n'hésite pas à les refaire au besoin et ne reviens sur le problème de cette perte de quelques fréquences d'horloge qu'une fois que tu as la certitude que tu ne peux plus gagner de temps ailleurs, et que cela en vaut réellement la peine ;)