Discussion :

[raphchar]

Bonjour

Utilisant un ifstream je veux obtenir la taille d'un fichier, classique

Code :

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

1
2
3
4
is.seekg (0, ios::end); //is est un ifstream
taille =is.tellg(); //taille est un long int
is.seekg (0, ios::beg);

sauf que ca ne marche pas avec un gros fichier exemple:
un fichier de 4.7Go donne 800 mo environ ce qui n'est pas normal.
Alors comment resoudre ce probleme?

raphchar

[3DArchi]

Salut,
Selon ton OS, long int peut être sur 32 bits. Utilises, si ton compilateur l'a, int64_t pour la transformation en valeur intégrale.

[raphchar]

Ca ne fonctionne pas (j'ai utilisé un __int64), et même résultat !

[Arzar]

Bonjour,

Tu es peut-être sur un vieux compilateur dont la biblio iostream standard ne savait pas gérer les fichiers de 4go ?

Pour en avoir le cœur net, que donne un sizeof(std::streamsize) ?
Si c'est 8 octets (64 bits) c'est bon, mais sinon tu es coincé.
Par exemple dans mes souvenirs la biblio iostream de Visual Studio a été adapté entièrement pour supporter les fichiers de plus de 4Go aux alentours de VS2005/2008

[raphchar]

J'ai vérifié, c'est bien 8, et j'utilise VS2010, bizarre !!

[Arzar]

J'ai vérifié, c'est bien 8, et j'utilise VS2010, bizarre !!

Je viens de vérifier avec VS2010.
Le problème est en effet présent... La biblio iostream de VS2010 est buggée avec des fichiers > 2Go

Confirmation ici :
https://connect.microsoft.com/Visual...n-x64-platform

c'est franchement inacceptable qu'un bug pareil se soit retrouvé dans une release officielle.
Microsoft n'a donc pas de jeu de test s'assurant que fstream fonctionne correctement avec des grands fichiers !!? C'est assez perturbant.
Donc raphchar, il me semble qu'il n'y a pas d'autre solution que de faire comme dans la FAQ C en utilisant GetFileAttributesEx...

[raphchar]

Bon, je suis fixé alors !!
La meilleurs solution est de changer de compilateur.

[Emmanuel Deloget]

Elle n'est pas buggée ; elle fait exactement ce qu'on lui dit de faire.

C'est à dire que tellg renvoie un objet du type streampos, qui est implicitement converti en int (quand on vous dit que les conversions implicite, c'est mal !) ; et l'int, sur une plateforme 32 bits, c'est 32 bits. Que tu le convertissent en int64_t ou pas derrirère, ça ne changera rien : le standard dit "int".

Le bug, si bug il y a, est dans le standard lui-même, pas dans la librairie (et on peut se demander à juste titre pourquoi est-ce que le standard considère qu'une position de stream est nécessairement un int ; ça, c'est un bug).

[Arzar]

Je ne suis pas d'accord, si je comprends bien le standard, le type renvoyé par tellg (pos_type) est implementation-defined. AHMA justement pour laisser toute latitude aux implémentateurs de choisir un type assez grand pour la manipulation de fichier.

Et il y a bien un bug dans la STL de VS2010, que ce soit sur platforme 32/64 bits, bug du à un mauvais cast:

streampos contains a 32-bit "conversion state", but also contains two 64-bit positions. The problem was that a 32-bit cast was hiding in a macro. We've fixed the cast, so large file support should work correctly now (regardless of x86/x64 platform)

Car si l'on remonte tout au bout de la définition de pos_type, on s’aperçoit que pos_type est en fait un typedef d'une struct nommée fpos, qui possède l'opérateur de cast suivant :

Code :

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

1
2
3
4
5
 
 __CLR_OR_THIS_CALL operator streamoff() const
   {	// return offset
     return ((streamoff)(_Myoff + _FPOSOFF(_Fpos)));
   }

Sous VS2010 la macro _FPOSOFF vaut #define _FPOSOFF(fp) ((long)(fp)).
Avec VS2011 preview la macro a été corrigé et vaut maintenant #define _FPOSOFF(fp) ((long long)(fp))

[Emmanuel Deloget]

Je ne suis pas d'accord, si je comprends bien le standard, le type renvoyé par tellg (pos_type) est implementation-defined. AHMA justement pour laisser toute latitude aux implémentateurs de choisir un type assez grand pour la manipulation de fichier.

Pas tout à fait : le standard dit que le type est implementation-defined, mais qu'il doit se comporter comme std::fpos<S>, ou S est implementation-defined lui aussi (avec quand même quelques requirement).

C'est le type fpos<S> qui est implicitement casté en int (et il a aussi un constructeur non implicite à partir d'un int).

Bref, le standard demande à ce que le résultat de l'expression stream.tellg(); soit transformé de manière implicite en int (j'ai relu ça 5 fois parce que je ne le croyais pas). cf. la table des requirements de fpos<> (je ne me rappelle plus le §).

A noter que ça n'a pas changé en C++11.

Moi, personnellement, je pense que c'est un bug du standard. Je ne vois pas pourquoi le standard force le type int. Il devrait forcé un type intégral signé implementation-defined capable de représenter toute position dans un fichier. Je ne vois pas l'intérêt de force le type int.

Par contre, ce a quoi tu fais référence est effectivement un bug de l'implémentation de la C++SL de VS2010, mais ça concerne un autre point. Car le même tableau défini aussi les conversions vers et à partir des types streamoff et streamsize. Or ces deux types doivent pouvoir représenter la taille maximale d'un fichier sur la plateforme, sous une forme signée (donc probablement un ssize_t ; ou long long dans le nouveau standard). Le cast en long sur une plateforme 32 bits est clairement mauvais.

Un autre problème se pose alors, parce ni streamoff, ni streamsize ne sont clairement défini. Par exemple, on ne sait pas s'ils possède un opérateur de cast (et vers quel type). Ces deux types contienent des états et rien dans le standard ne dit comment récupérer ces états. Du coup, le problème reste plus ou moins entier

[Klaim]

Donc au final, hors code initial, pour avoir la vrai taille d'un gros fichier en C++ on a quoi?


1. Visiblement ya une fonction dans boost donc si on a boost sous la main on peut appeler file_size() : http://www.boost.org/doc/libs/1_48_0...html#file_size

Est-ce que quelqu'un a déjà vérifié que ça marche sur les gros fichiers?

2. Parcourir un filestream jusqu'à la fin en comptant les octets?
3. Une autre solution?

Le sujet est interessant parceque si il n'y a aucun moyen correcte d'obtenir la taille d'un gros fichier en C++, on est pas dans la merde...

[JolyLoic]

Pas tout à fait : le standard dit que le type est implementation-defined, mais qu'il doit se comporter comme std::fpos<S>, ou S est implementation-defined lui aussi (avec quand même quelques requirement).

C'est le type fpos<S> qui est implicitement casté en int (et il a aussi un constructeur non implicite à partir d'un int).

Je n'ai pas vu ce cast en int (même s'il existe bien la construction depuis int, ce qui peut être bien pratique, surtout quand le int vaut 0, ainsi que la construction depuis un stream_off)

Bref, le standard demande à ce que le résultat de l'expression stream.tellg(); soit transformé de manière implicite en int (j'ai relu ça 5 fois parce que je ne le croyais pas). cf. la table des requirements de fpos<> (je ne me rappelle plus le §).

Table 127 en C++11

Moi, personnellement, je pense que c'est un bug du standard. Je ne vois pas pourquoi le standard force le type int. Il devrait forcé un type intégral signé implementation-defined capable de représenter toute position dans un fichier. Je ne vois pas l'intérêt de force le type int.

C'est bien ce qui est indiqué en 27.1 pour stream_off (figure 7):
signed integer type sufficient for O/S maximum file size

Sachant que fpos est entièrement convertible bidirectionnellement en stream_off

[Emmanuel Deloget]

Je n'ai pas vu ce cast en int (même s'il existe bien la construction depuis int, ce qui peut être bien pratique, surtout quand le int vaut 0, ainsi que la construction depuis un stream_off)

Dingue ça. Je suis sûr de l'avoir vu quelque part, et je n'arrive pas à remettre la main dessus.