Discussion :

[sgmsg]

Bonjour à tous

J'utilise une routine pépère de lecture

Code :

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

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
34
35
36
function lisfichier(var donnees:string;const Nomfichier:string):boolean;
var fs:tfilestream;
    f:tsearchrec;
    erreur,taille:integer;
begin
    result:=false;
    donnees:='';
    if not fileexists(Nomfichier) then begin
        exit;
//        showmessage(Fichier+' introuvable');
//        beep;
    end;
    erreur:=findfirst(nomfichier,faanyfile,f);
    taille:=f.Size;
    SysUtils.findclose(f);
 
    if erreur>0 then exit;
    if taille=0 then begin result:=true;exit;end;
 
//lecture
    try
        fs:=tfilestream.create(Nomfichier,fmOpenRead );
    except
//        communique('Litfichier: Impossible de lire le fichier '+fichier);
        try
            freeandnil(fs);//ce free déclenche occasionnellement une erreur vriament étrange.
        except
        end;
        exit;
    end;
    setlength(donnees,taille);
    fs.read(PChar(donnees)^,taille);
//        fs.Destroy;
    freeandnil(fs);
    result:=true;
end;

Mais quand je compare avec 7zip, ça me semble très lent...

Auriez-vous une routine qui arrache?

Merci

[ShaiLeTroll]

En fait, tu fais plein de truc en double tfilestream va aussi faire le FileExists, une exception sera renvoyé si tu ne peux pas l'instancier, la classe d'excep
ption EFileStreamError par exemple

FindFirst, pas plus utile puisque que tfilestream contient une propriété Size, FindFirst lance une recherche, ce n'est pas si léger que cela

Enfin, tu charges tout le fichier en mémoire, imaginons, ton PC à 1Go donc 600Mo déjà occupé, tu ouvres un fichier de 500Mo, tu auras du mal à atteindre le 1Go de RAM en réalité que Windows commence à faire du SWAP donc ton fichier chargé en mémoire se retrouve finalement écrit sur disque !

Ce code sous D7 est valable, attention sur D2009 et XE, mauvaise surprises, tu va lire un buffer brut vers une chaine UnicodeString, le nombre d'octet ne correspond a au nombre de Char (en général, c'est 2 octet par char en UTF16, ça monte à 4 pour les langues que l'on utilise pas souvent en france où l'on a fréquemment que le BMP )

ce free déclenche occasionnellement une erreur vriament étrange.

Non c'est tout à fait normal !
Si une exception se produit durant le TFileStream.Create alors fs n'est jamais affecté, la valeur fs est aléatoire, parfois c'est zéro donc le Free ne provoque pas d'erreur et d'autres fois cela contient une valeur non zéro considéré comme un pointeur, cela tente de libérer un objet qui n'existe pas !

Voici un code bien suffisant, si l'on reste dans l'état d'une lecture brute de décoffrage

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
function lisfichier(var donnees:AnsiString; const Nomfichier: TFileName):boolean;
begin    
  try
     with TFileStream.Create(Nomfichier, fmOpenRead) do
     try       
       Result := true;
       SetLength(donnees, Size);
       if Size > 0 then 
         Read(PAnsiChar(donnees)^, Size); 
     finally
       Free();
     end;
  except
    on E: Exception do 
    begin
      // communique('Litfichier: Impossible de lire le fichier (erreur : '+E.Message+') : '+fichier);
      Result := false;
    end;
  end;   
end;

[sgmsg]

Ta routine arrache!!!

Merci

C'est comme trois fois plus vite.

Mon vieux PC va être soulagé

Je comprend bien ton explication sur le fs parfois zéro parfois pas. Mais j'aurais jamais compris cela tout seul.

Merci encore !!!