Position curseur dans un fichier texte [C++]

Signaler
Messages postés
18
Date d'inscription
mardi 10 août 2004
Statut
Membre
Dernière intervention
25 août 2004
-
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
-
Salut !

Je cherche à comprendre le bogue dans un programme tout simple qui me permet de récupérer la position du curseur (en nombres de lignes) en fin de fichier. Le nombre de lignes retournées par mon code est plutôt bizarre, il est de -9 !?!?! Alors qu'il devrait me retourner 35441 !?!

Est-ce que quelqu'un peut m'aider??? Si vous avez d'autres suggestions, n'hésitez pas!

Pour votre information le fichier toto.txt est composé de 35441 lignes dont chacune comprend 3 nombres décimaux espacés par un tab (la 35441ème ligne du fichier est vide).

Merci =)
_____________________

Voici mon code :

streampos nb_lignes;
ifstream fichier("toto.txt", ios::binary);
fichier.fseekg(0, ios::end);
nb_lignes = fichier.tellg() - sizeof(double);
fichier.close();
cout << "NB_LIGNES = " << nb_lignes << endl;

______________________

23 réponses

Messages postés
18
Date d'inscription
mardi 10 août 2004
Statut
Membre
Dernière intervention
25 août 2004
1
s'cuser moi l'ignorance, mais n'étant pas une pro de la prog, ça me dit absolument rien de mettre ça dans un buffer. Est-ce qu'il y a quelqu'un qui pourrait m'expliquer comment je peux incorporer ça à mon code ???? Ça serait vraiment gentil !

Merci encore pour les infos =)
Messages postés
6535
Date d'inscription
lundi 16 décembre 2002
Statut
Modérateur
Dernière intervention
22 août 2010
7
tu dois avoir des gros doubles!
Messages postés
3011
Date d'inscription
jeudi 26 septembre 2002
Statut
Membre
Dernière intervention
27 novembre 2004
8
le nombre de lignes dans un fichier binaire ?
Messages postés
18
Date d'inscription
mardi 10 août 2004
Statut
Membre
Dernière intervention
25 août 2004
1
Ouain... je viens de cogiter sur mon problème !!! Ça faisait aucun sens ! Finalement, voici le programme que j'ai ajouté à mon code.
C'est en code C, j'aurais préféré l'avoir en C++ pcq tout le reste de mon code est en C++, mais j'ai pas trouvé comment le modifier... L'important c'est que là, ça marche !!!

Si vous avez des suggestions pour transformer ce code en C++, je les attends avec impatience !!!

Merci =)

--------------------------
Voici le code :

int nb_lignes = 0;
char c;

FILE *fichier;
fichier = fopen("toto.txt", "r");

if (fichier == NULL)
{
cout << " Aucun fichier detecte ! " << endl;
exit(1);
}
else
{
do
{
c = fgetc(fichier);
if (c == '\n')
{
nb_lignes ++;
cout << nb_lignes << endl;
}
} while ( !feof(fichier) );
}
cout << " Nombre de lignes totales du fichier = " << nb_lignes << endl;
Messages postés
3011
Date d'inscription
jeudi 26 septembre 2002
Statut
Membre
Dernière intervention
27 novembre 2004
8
while( (c = fgetc(fichier)) != EOF ) if(c == '\n') nb_lignes++;

et en c++

ifstream fichier( "toto.txt" );
while( fichier.good() ) if( fichier.get() =='\n' ) nb_lignes++;
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
28
Tu pourrais au moins comptabiliser les '\n' dans un buffer, serait autrement plus rapide.

ciao...
BruNews, Admin CS, MVP Visual C++
Messages postés
3011
Date d'inscription
jeudi 26 septembre 2002
Statut
Membre
Dernière intervention
27 novembre 2004
8
oui, c'est sur qu'il vaut mieux utiliser un buffer
Messages postés
3011
Date d'inscription
jeudi 26 septembre 2002
Statut
Membre
Dernière intervention
27 novembre 2004
8
FILE *file;
char *buffer, *p;
long size;
size_t i = 0, nb_lines;

if( !(file = fopen( "toto.txt", "r")) ) exit(1) ;

fseek( file, 0, SEEK_END);
size = ftell( file );
rewind( file );

buffer = malloc( size );
fread( buffer, size, 1, file );
fclose( file );

p = buffer;
while( i++ < size ) if( *p++ == '\n' ) nb_lines++;

free( buffer );
Messages postés
83
Date d'inscription
mardi 24 février 2004
Statut
Membre
Dernière intervention
10 mars 2006

salut,

faut faire gaffe aussi au type que t'utilises pour calculer le nombre de lignes, parce que si la variable est sur 16 bits ça peut faire un dépassement et tu auras un nombre négatif comme dans ton cas où tu devais avoir 35441 lignes.
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
28
Une variable de 16 bits ne s'emploie plus depuis 10 ans.

ciao...
BruNews, Admin CS, MVP Visual C++
Messages postés
83
Date d'inscription
mardi 24 février 2004
Statut
Membre
Dernière intervention
10 mars 2006

un short est bien sur 16 bit ?
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
28
short est bien sur 16 bits mais on utiliserait jamais cela en variable compteur par exemple.

ciao...
BruNews, Admin CS, MVP Visual C++
Messages postés
83
Date d'inscription
mardi 24 février 2004
Statut
Membre
Dernière intervention
10 mars 2006

ok. c'est parce que j'ai pas trop l'habitude. vu que j'utilise plutot l'info pour l'electronique ça se limite généralement aux unsigned char.
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
28
ah ok, me semblait bizzare ton affaire.
Faut utiliser 'int' qui sera 32 bits sur processeur 32 bits et ne souffrira d'aucune penalite en temps d'acces, l'octet non plus d'ailleurs mais le 'short' SI, tu y perdrais donc en vitesse comme en quantite stockable.

ciao...
BruNews, Admin CS, MVP Visual C++
Messages postés
83
Date d'inscription
mardi 24 février 2004
Statut
Membre
Dernière intervention
10 mars 2006

ok merci de l'info
Messages postés
3011
Date d'inscription
jeudi 26 septembre 2002
Statut
Membre
Dernière intervention
27 novembre 2004
8
BruNews > sur les docs des processeur (x86), il est dit (pour les entiers) d'utiliser au maximun des unsigned pour les compteur, indexer un tableau, et autres operations de bases sur les entiers (surtout division et modulo)

j'utilise moi meme des unsigned mais j'ai fais le teste sur l'indexation d'un tableau et il se trouve que c'est 2 fois plus rapide avec un signé, c'est normal ?
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
28
Je ne pense pas que soit la doc des 'processeurs' mais des compilos. Un processeur (ASM) ignore la difference signed unsigned, il n'y a que des registres, la diff est seulement comment on le regarde (EFLAGS) a un certain moment. Il est certain que le compilo doit generer des instructions plus longues (en taille) pour recupere le bit haut s'il est positionne et que tu declares int au lieu de DWORD, il n'y a par contre aucune raison que soit plus lent avec l'un ou l'autre dans le cas d'une variable compteur incrementee, tout dependra de la forme de l'algo.

ciao...
BruNews, Admin CS, MVP Visual C++
Messages postés
3011
Date d'inscription
jeudi 26 septembre 2002
Statut
Membre
Dernière intervention
27 novembre 2004
8
donc en regle generale il n'y a aucune raison de preferer les non signés aux signés ?
est-ce que l'alu d'un processeur x86 considere le signe d'un entier?

dans la doc ils disent egalement qu'un entier signé sera converti en float plus rapidement qu'un entier non signés car les processeur dispose d'une instruction (asm) qui convertit un entier signé en float, mais j'ai pas vu de difference
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
28
Prefere les non signes si tu peux dans le cas de nombreuses divisions, c'est la pire operation qu'on puisse infliger au processeur.
Un entier en asm n'a pas de signe:
int i;
i-- sera: dec edi
DWORD i;
i-- sera toujours: dec edi
le prob va se poser quand on analysera le positionnement EFLAGS resultant, encore une boucle si != 0 alors 'jnz boucle' mais il n'y a pas de difference fondamentale.
Aucune diff non plus en chargement dans la fpu, utilisera 'fild' si tu as dit 'int' sinon 'fld', tous les 2 chargent depuis un emplacement memoire et jamais direct depuis un registre, une grande partie de la perte de temps est la, pas dans le fait que soit signe ou non.

ciao...
BruNews, Admin CS, MVP Visual C++
Messages postés
3011
Date d'inscription
jeudi 26 septembre 2002
Statut
Membre
Dernière intervention
27 novembre 2004
8
ok merci, mais ca ve dire que je peux pas me fier a cette doc ?