FUSION BIT - PERMET DE COLLER DES FICHIER BOUT À BOUT
cs_aKheNathOn
Messages postés
575
Date d'inscription
dimanche 23 décembre 2001
Statut
Membre
Dernière intervention
23 octobre 2012
-
12 juil. 2002 à 20:05
tdikarimgrps Messages postés 16 Date d'inscription samedi 21 octobre 2000 Statut Membre Dernière intervention 9 août 2002 - 15 juil. 2002 à 09:41
tdikarimgrps Messages postés 16 Date d'inscription samedi 21 octobre 2000 Statut Membre Dernière intervention 9 août 2002 - 15 juil. 2002 à 09:41
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/4004-fusion-bit-permet-de-coller-des-fichier-bout-a-bout
https://codes-sources.commentcamarche.net/source/4004-fusion-bit-permet-de-coller-des-fichier-bout-a-bout
15 juil. 2002 à 09:41
Ca marche super bien (la taille de mes fichiers ne sont pas gigantestque).
Merci aux autres qui apporte des infos et précision suppl. c'est toujours bon à savoir.
@+
13 juil. 2002 à 21:14
La source 5100 fait la meme erreur que toi : il utilise des strings ! mais il ne charge pas entièrement le fichier en RAM: en effet il ne charge, de l'original, que la quantité de données qui sera inscrite dans un des fragment, et lors de la reconstitution, il récupère un fragment en mémoire puis l'inscrit tout de suite dans le globale. Il n'y a pas de concaténation de strings, donc ca va "vite"...
... mais question mémoire, s'il utilisai un tableau de byte à la place des strings et redim() au lieu de la fonction string() ça prendrai 2 fois moins de place en RAM. voila (et ça serai plus rapide, si on veux faire des fragment de 15Mo d'un fichier de 600Mo)
quant a la fonction copy, lol :) ,faites copy /? et vous verrez que vous pouvez copier tout un dossier vers un seul fichier :) le dos n'est pas aussi merdique que les pro-linux veulent vous faire croire!
Pourquoi est-ce rapide sous dos, me demanderez-vous ? bah parce que les copies se font par flux de données et non par chargement de fichier/écriture sur disque ... et en vb la gestion de flux, ben on ne peux que "l'émuler" ...
13 juil. 2002 à 16:32
copy /b fichier1.ext + fichier2.ext fichierassemblé.ext
Bon bien sur, c'est toujours interressant de savoir programmer ça mais bon... :)
13 juil. 2002 à 11:33
http://www.vbfrance.com/article.aspx?Val=5100
Et niveau mémoire , je sait pas ce qu'il en pense Proger , mais la source du gars ne doit pas trop en bouffer vu que c'est un traitement progressif ...
13 juil. 2002 à 11:08
13 juil. 2002 à 09:38
copy /b
ça fait la meme chose !
12 juil. 2002 à 21:31
ça serais même cool que les gars qui voient les bugs les expliquent comme toi tu le fais .
Je ne connaissait pas l'utilitée de la variable unicode , donc depuis tj j'ai utilisé des fonctions style comme ça ... (mais bon ça va vite changer grace à toi)
Bon je fais une mise à jour en speed ...
PS : Pas mal la remarque du FileCopy , j'aurais du y penser ...
12 juil. 2002 à 21:08
Pourquoi ? simple : tu stocke le contenu des fichiers dans 2 variables string. Et là, horreur : un caractère prend 2 octets en mémoire (unicode powa, faut le savoir). Donc si j'ouvre deux big fichier de 40Mo , sa prendra donc 80 + 80 = 160 Mo en mémoire ! mmh c'est pas gentil, ca ... l'excuse "oui mais moi j'ai 256 de ram" est absolument innacceptable (bravo la compatibilité : est-ce sérieux d'écrire "fusion de fichier : nécessite un 486DX avec 512 de ram" ??)
En outre, faire une concaténation de deux string (exebuffer & xlabuffer) lorsque ces string dépasse le Mo, je ne dirais que ça : aargh! - en effet, c'est atroce pour le cpu.
Donc deja : utilisez un tableau de byte !!!!! sa bouffera deux fois moins de mémoire (et c'est aussi facile à utilisé que les strings$)
Et ensuite : ne charger pas Intégralement un fichier en mémoire !!! prenez-en 1Mo par 1Mo et écrivez-là dans la destination, (do ... loop powa)
Puis enfin : si tu recolle un fichier B à la fin d'un fichier A, a quoi sa sert de charger en mémoire le fichier A ? fais une copie du fichier A (filecopy) et rajoute a la fin le fichier B !!! (soit via open "A" for append, soi via open "A" for binary puis seek #,lof("A") )
Bon, je vois que c'est "en réponse à la question posé par..." : peut-être que sa question étais "je charge deux fichier en mémoire : comment je les colle ensemble?" - si c'est le cas, ce code est la réponse (print #, fichierA$ & FichierB$)
PS: m'en veux pas akhenathon ... j'essai d'être constructif...
12 juil. 2002 à 20:05