Violation de la Mémoire ?!

Version imprimable

Bonjour, j'ai bon me tourner la tete dans tous les sens, je ne vois pas mon probleme dans ce code.

Code:

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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
unit LogActions;
 
interface
 
uses SysUtils, Classes, SyncObjs;
 
function GetLogs: TStrings;
 
implementation
 
var
  CS: TCriticalSection;
  FileName: String;
 
function GetLogs: TStrings;
var
  LogFile: TextFile;
  Ligne: String;
begin
  CS.Acquire;
 
  if not FileExists(FileName) then
  begin
    Result.Text := '(vide)';
    Exit;
  end
  else
  begin
    AssignFile(LogFile, FileName);
    Reset(LogFile);
  end;
 
  while not EoF(LogFile) do
  begin
    ReadLn(LogFile, Ligne);
    Result.Add(Ligne);
  end;
 
  CloseFile(LogFile);
 
  CS.Release;
end;
 
initialization
  if not Assigned(CS) then CS := TCriticalSection.Create;
  FileName := 'logs.txt';
 
finalization
  CS.Free;
 
end.

Enfait, il parcours bien a chaque ligne, et arrivé à la derniere, il plante en me donnant comme erreur une violation de la mémoire.

Salut

Je te propose plutot ceci:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
procedure GetLogs(Log: TStrings; Filename: TFilename);
begin
  if not FileExists(Filename) then
    Log.Text := '(Vide)'
  else
    Log.LoadFromFile(Filename);
end;
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  GetLogs(Memo1.Lines, 'c:\MonFichier.log');
end;

Merci beaucoup, j'ai finalement opté pour

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
function GetLogs: TStrings;
begin
  CS.Acquire;
 
  Result := TStringList.Create;
 
  Result.Text := '(Vide)';
 
  if FileExists(Filename) then
    Result.LoadFromFile(Filename);
 
  CS.Release;
end;

Merci beaucoup encore ^^

04/05/2007, 20h10
CapJack

Ben oui, l'objet Result de GetLogs n'était instancié à aucun moment... il est étrange que le code ne plantait pas dès la première référence à Result.

Par contre dans la deuxième version, il ne faudra pas, après usage, oublier de libérer l'objet renvoyé par la fonction, afin d'éviter une consommation inutile de mémoire.
05/05/2007, 09h31
Korko Fain

Détails un peu plus stp ça m'interesse ^^

Code:

1 2 3 4 5 6 var Logs : TStringList; ... Logs := GetLogs; // Tout ce que je dois faire avec Logs ... Logs.Free;
En effet, à chaque fois que GetLogs est appelée, un nouvel objet est créé, qu'il faut donc libérer. C'est le genre d'erreur qu'on fait facilement, et qui provoque les fameuses "fuites de mémoire".

En outre, dans un grand projet, on finit par ne plus savoir quoi instancie quoi et quoi doit libérer quoi, ce qui finit par rendre le projet impossible à maintenir correctement.

Sauf nécessité absolue, on s'interdit d'instancier des objets à l'intérieur d'une fonction ou d'une procédure, en vue d'un retour vers l'extérieur de la fonction ou de la procédure.

Imagine ceci :

Code:

Memo1.Lines := GetLogs;

C'est un code qui fonctionne, mais tout à fait épouvantable, puisqu'il n'y a aucun moyen de libérer l'objet créé par GetLogs. Si ce code est appelé en boucle, tous ces objets vont s'accumuler dans la mémoire, jusqu'à saturation.

La bonne méthode est de transmettre en paramètre un objet déjà instancié servant de receveur. Il n'est même pas nécessaire de le passer en paramètre var, d'ailleurs, à cause de la "pointeurisation" automatique des objets, ce qui permet des raccourcis de code.

Le code de Cl@udius est donc la bonne méthode, qu'on peut compléter comme suit :
Code:

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 procedure GetLogs(Log: TStrings; Filename: TFilename); begin CS.Acquire; if not FileExists(Filename) then Log.Text := '(Vide)' else Log.LoadFromFile(Filename); CS.Release end; // Type d'utilisation 1 : objet déjà instancié procedure TForm1.Button1Click(Sender: TObject); begin GetLogs(Memo1.Lines, 'c:\MonFichier.log'); end; // Type d'utilisation 2 : objet que j'instancie puis libère au même bloc // rendant ainsi le code plus propre et plus lisible (un .Create pour un .Free) procedure TForm1.Button2Click(Sender: TObject); var Logs : TStringList; begin Logs := TStringList.Create; GetLogs(Logs, 'c:\MonFichier.log'); ... // Je fais ce qui me plaît avec Logs. Logs.Free; end; // Type d'utilisation 3 : utilisation d'un objet TStringList déclaré dans la fiche, // Instancié une fois au démarrage dans FormCreate, // libéré à la sortie dans FormClose. Je ne tape pas le code, trop long.

05/05/2007, 11h32
Korko Fain

Très intéréssant. Peut tu m'expliquer mieux pourquoi on ne peux pas controler l'objet lorsqu'on fait Memo1.Lines := GetLogs; ?
N'y a t'il pas pointeurisation et donc plus tard, lors de la destruction de Memo1.Lines, n'y a til pas désalocation de la mémoire ?

Lorsqu'on réafecte la valeur, il n'y a pas destruction de l'ancienne ?
05/05/2007, 16h55
CapJack

Parce que Memo1.Lines est une propriété, dont l'affectation se traduit par une copie de l'objet, comme la plupart des affectations propriété:=variable, la VCL étant ainsi conçue (en fait le tableau associé à la propriété Lines n'est détruit qu'à la libération de l'objet TMemo lui-même, jamais par une affectation).

Les affectations variable:=variable, par contre, effectuent seulement une copie de pointeur.

Oui, je sais... :roll: tu peux commencer à comprendre à quel point la transformation du Pascal en Pascal Objet par Borland a fait l'objet de choix parfois très discutables.

Raison de plus pour être prudent et faire un code bien symétrique au niveau instanciation/libération, ce qui limitera les éternelles questions sur, soit les fuites de mémoire (trop d'instanciations ou pas assez de libérations), soit les violations d'accès (trop de libérations ou pas assez d'instanciations). ;)
06/05/2007, 11h53
Korko Fain

Merci beaucoup. Tres intéréssant ce petit cours ^^ Je vais voir pour effectuer ces modifications ;)

Merci encore ;)