Version imprimable
Bonjour,
J'utilise actuellement les library "stdio.h" , fseek, fopen... pour gerer un fichier binaire sous winxp64. Malheureusement, mon fichier fait parfois plus de 2GB et alors toutes ces fonctions plante lamentablement.
Comment faire, ou quelle library utiliser pour ecrire et lire des fichier > 2 GB
merci d'avance
L'API système (Platform SDK) directement.... ou alors sous MSVC++ la stdlib propose des versions "correctes" des fonctions de file-management (avec notamment des unsigned __int64 pour les tailles) si je me souviens bien.
Comme d'ailleurs pour la plupart des fonctions (gestion des chaines, ...).
Ok, mais moi je voudrais quelque chose de portable, du C++
Vu le message originel, il était pas évident que ce soit pour être portable (winxp64), ni forcément C++ (stdlib).
Tu trouveras alors peut-être ton bonheur dans 'boost'.
La stdlib est si vieille (si sure :aie: , et si souvent mise à jour :? ) que c'est plus une plaie à utiliser qu'autre chose. Mais c'est un avis que je partage avec moi-même :)
Sous Win64, les size_t sont supposés faire 64 bits, après il faut s'assurer que les fonctions d'accès aux fichiers suivent.
Si ça ne suit pas, tu sera réduit à utiliser l'API système...
Tu parles de quoi là ?Citation:
La stdlib est si vieille (si sure , et si souvent mise à jour ) que c'est plus une plaie à utiliser qu'autre chose. Mais c'est un avis que je partage avec moi-même
De stdio.h et consorts :)Citation:
Envoyé par loufoque
Oui sous Windows 64, compilé pour x64. Les fonctions devraient marcher.Citation:
Envoyé par Médinoc
Dès qu'on compile pour x32... size_t revient à 32 bits ... et du coup, même sous Windows x32 ca ne marche pas (parcequ'on peut quand même avoir des fichiers de quelques centaines de Go sous Windows x32 ! :D).
Pour la gestion mémoire size_t est très bien... pour les fichiers, offset et tailles devraient être des int64 (ou equivalents), jusqu'à ce que les disques de 16 exa-octets (16777216 To) fassent leur apparition.
De la bibliothèque standard C tu veux dire ? En général ou dans le cas de son implémentation dans VC++ ?
Il faut impérativement utiliser des API systemes comme le dit Nicroman.Citation:
Envoyé par uriotcea
Jouer sur la pagination de la mémoire.
Oublies carrément la portabilité , la gestion mémoire c'est bcp trop spécifique à l'OS.
Si tu veux faire qque chose de portable tu ne peux pas optimiser...
je ne sais pas ce que c'est que cette mode de vouloir faire portable à tout prix.
N'importe quoi Mat.M.
La seule chose qui empêche ici de manipuler les fichiers de plus de 2 Gio avec la bibliothèque standard c'est qu'elle n'est pas implémentée correctement.
Il n'y aucunement besoin de passer par des éléments spécifiques au système d'exploitation.
Je sais pas ce que c'est que cette mode de se rajouter des dépendances et de se limiter à des systèmes spécifiques quand on peut travailler avec une abstraction portable...
Il faudrait pas exagérer non plus.Citation:
Si tu veux faire qque chose de portable tu ne peux pas optimiser...
d'accord alors il fait ce qu'il veut s'il a raison et on en reparle quelques temps après...puisque je raconte n'importe quoi ..Citation:
Envoyé par loufoque
je ne parle pas de rajouter des dépendances ou quoique ce soit simplement avec les fonctionnalités "standards" cela ne peut fonctionner dans certains cas...
Uriotcea si tu programmes sous Windows je te conseille vivement de consulter le MSDN mieux si tu le trouves le livre de Jeffrey Richter "Inside Win Nt" je crois qui parle de la gestion de la mémoire,threads et fichiers.
Enfin tu fais ce que tu veux vu que je dis n'importe quoi...
après tout si ton projet pédale ce ne sera pas de ma faute..:roll: et qu'il y a des gens qui ne jurent que par la portabilité
Entre l'un et l'autre il y a un juste milieu... et la gestion des fichiers est le truc implémenté en premier par les librairies de portabilité comme boost. Un peu comme la gestion des chaînes de caractères (oui std::string c'est très bien) et des charsets, des threads, de la mémoire, et de plein d'autres choses tellement spécifique à l'OS, qu'il n'y a aucune spécification C, ou C++.
Des langages plus récents comme Java, et C# intègrent parfaitement ces éléments.
La libraire C standard est ce qu'elle est, et certaines fonctions (simplement par leur déclaration) ont du mal sur les machines récentes...comme:
C'est d'ailleurs, si mes souvenirs sont bon, la seule fonction de stdio qu'on ne puisse pas vraiment utiliser. Mais c'est quand même rare quand on en a besoin.Code:long int ftell ( FILE * stream );
Si tu nous disais exactement ce qui foire, on pourrait peut-être dire comment faire...
Ok OK, la seule chose que je demande c'est comment me déplacer dans un fichier de plus de 2GO. Autrement dire qui remplace fseek(...). qui n'accepte que des entrées limitées à 32Bits
Et t'as lu ça où ?Citation:
fseek(...). qui n'accepte que des entrées limitées à 32Bits
TON implémentation de fseek n'accepte que des entrées limitées à 32 bits. Le standard ne dicte rien de tel, et il est techniquement tout à fait possible techniquement d'étendre cela à la taille qu'on veut.
J'ai du mal à voir comment utiliser autre chose qu'un long et rester conforme. Et ce à que réfère long est plus difficile à changer.Citation:
Envoyé par loufoque
L'interface C++ est plus souple.
En effet...
La version bas-niveau POSIX, elle, prend un off_t en paramètre, ce qui la rend assez flexible, mais on dirait bien qu'en C, la taille d'un fichier soit limitée à la valeur maximale d'un long...
À moins bien sûr, de renoncer à l'accès aléatoire, ou peut-être de faire plusieurs fseek() à la suite.
Loufoque, la commande fseek(..) attendant un long comme argument, essayer d'y mettre un un "long long" revient à y mettre un nombre négatif !!!!!
Je l'ai lu null part, j'ai just essayé, mais de toute maniere c'est évident
La taille d'un long n'est pas dictée par le standard.
De toutes manières, l'interface standard C++ ne fixe pas le type. Donc les problèmes éventuels liées au typage fixé de la bibliothèque standard C sont relativement peu importants.
Je veux bien croire tout ce que tu veux. Ecrit moi le bout de code permettant de se possitionner à la position 3 GO sur un fichier de 4 GO. Je suis preneur.
Et? Implementer un langage, ce n'est pas un jeu formel mais pragmatique. Le choix de la taille d'un long va dependre d'un tas de choses, et le fait que le systeme en question soit capable de gerer des fichiers de plus de 2Gb est un critere qui doit se retrouver tout en bas de la liste.Citation:
Envoyé par loufoque
Qu'ai-je ecrit d'autre?Citation:
De toutes manières, l'interface standard C++ ne fixe pas le type. Donc les problèmes éventuels liées au typage fixé de la bibliothèque standard C sont relativement peu importants.