BoolToStr wirft Memcheck Exception.

[RWarnecke]

Zitat von pertzschc:

Daher der Zugriff auf alle public properties des Objektes für das Speichern. Hältst Du das für falsch?
Gruß,
Christoph

Ich benutze immer lokale Variablen und keine globalen Variablen. Es geht da bei um das Freigeben der Klasse. Ich habe das gleiche Problem auch noch in einer meiner Klassen. Ich habe im Interface-Teil eine Variable deklariert. Diese Variable erstelle ich im constructor und gebe Sie wieder im Destructor frei. Da habe ich das gleiche Problem. Ich habe schon die ersten Anfänge gemacht und alles auf die private/protected Variablen umzustellen und meine Memory-Leaks verschwinden wie von Zauberhand.

Funktioniert es denn, wenn Du es abänderst, wie ich es geschrieben habe ?

Edit:
Deine Proberty schreibt und liest doch den Wert fNumberWithZero, warum sollte es nicht funktionieren ?

[pertzschc]

Zitat von RWarnecke:

Deine Proberty schreibt und liest doch den Wert fNumberWithZero, warum sollte es nicht funktionieren ?

Nein, die function ist eine in der Unit deklarierte globale Funktion. Sie bekommt als Argument ein Objekt, welches ein TestProject darstellt. Dieses Objekt hat public properties, an denen jeweils eine Set/Get-Methode hängt.
Diese Eigenschaften des Objektes werden dann in der Save-function als Werte in eine INI-Datei geschrieben. Daher ist kein Zugriff innerhalb der function auf private Eigenschaften des übergebenen Objektes möglich. Dann müsste ich die fAttribute public machen und auf Set/Get-Methoden der Properties verzichten. Das macht für mich keinen Sinn wenn ich hier kapseln möchte. Hilft diese Erklärung zum besseren Verstehen?

Delphi-Quellcode:

type
  TTestProject = class(TObject)
  private
    { Private declarations }
    fName: string;                 // name des projektes
    fNumberWithZero: boolean;  // sollen nach dem prefix der nummernbereich mit nullen aufgefüllt werden?
    ...
    // methoden
    procedure Set_NumberWithZero(aNumberWithZero: boolean);
    function Get_NumberWithZero: boolean;
    ...
  public
    { Public declarations }
    // properties
    property Id: string read Get_IdStr;
    property Name: string read fName write fName;
    property NumberWithZero: boolean read Get_NumberWithZero write Set_NumberWithZero;
    ...
    // konstruktor etc...
    constructor Create; overload;
    destructor Destroy; override;
  end;

Gruß,
Christoph

[RWarnecke]

Irgendwie verstehe ich das nicht ganz. Im Beitrag 3 haste noch diese Zeile geschrieben :property NumberWithZero: boolean read fNumberWithZero write fNumberWithZero; Jetzt soll die Zeile so heissen :property NumberWithZero: boolean read Get_NumberWithZero write Set_NumberWithZero; Was ist denn nun richtig ?

Ein Memory Leak ist ja nichts anderes, Du hast Speicher reserviert und gibst diesen nicht wieder frei. Dieses muss ja innerhalb der Ermittlung von der Property NumberWithZero passieren. Zum Beispiel :

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  numbers : TStringList;
begin
  numbers := TStringList.Create;
  numbers.Add('Testeintrag 1');
end;

Bei dieser Procedure wird auch ein Memory Leak angezeigt für die Stringliste.


Edit:
Hast Du schonmal mit EurekaLog das ganze untersucht. Eurekalog zeigt Dir den ganzen Weg auf, von da wo es auftritt, bis zum Ursprung.

[Bernhard Geyer]

Hast du evtl. Compileroptimierungen an? Darauf reagiert AFAIK MemCheck allergisch.
Ich würde eh FastMM verwenden. Vorteile zu MemCheck:

- Zusätzlich besserer Memory Manager
- Wird noch aktiv weiterentwickelt.

[pertzschc]

Zitat von RWarnecke:

Irgendwie verstehe ich das nicht ganz. Im Beitrag 3 haste noch diese Zeile geschrieben :property NumberWithZero: boolean read fNumberWithZero write fNumberWithZero; Jetzt soll die Zeile so heissen :property NumberWithZero: boolean read Get_NumberWithZero write Set_NumberWithZero; Was ist denn nun richtig ?

Beides ist richtig. Die Set/Get-Methoden sind die Weiterentwicklung, anfangs war es noch ein direkter read/write auf das private Attribut.

Zitat von RWarnecke:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  numbers : TStringList;
begin
  numbers := TStringList.Create;
  numbers.Add('Testeintrag 1');
end;

Bei dieser Procedure wird auch ein Memory Leak angezeigt für die Stringliste.

Das Beispiel passt für mein Problem nicht ganz. Bei mir würde ich jetzt:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  test : boolean;
begin
  test := BoolToStr(Sender.IsChild, true);
end;

als Code haben. Dann meckert Memcheck in der Zeile:
  test := BoolToStr(Sender.IsChild, true);

Zitat von RWarnecke:

Hast Du schonmal mit EurekaLog das ganze untersucht. Eurekalog zeigt Dir den ganzen Weg auf, von da wo es auftritt, bis zum Ursprung.

Danke für den Tipp, werde ich mir mal anschauen.

[pertzschc]

Zitat von Bernhard Geyer:

Hast du evtl. Compileroptimierungen an? Darauf reagiert AFAIK MemCheck allergisch.
Ich würde eh FastMM verwenden. Vorteile zu MemCheck:

- Zusätzlich besserer Memory Manager
- Wird noch aktiv weiterentwickelt.

Die Optimierungen sind aus, wenn im dpr-File Memcheck eingebunden ist.

Danke für den Tipp mit FastMM. Funktioniert das auch mit Delphi 7 und wo kann ich ein Tutorial dazu finden?

Gruß,
Christoph

[RWarnecke]

Zitat von pertzschc:

Das Beispiel passt für mein Problem nicht ganz. Bei mir würde ich jetzt:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  test : boolean;
begin
  test := BoolToStr(Sender.IsChild, true);
end;

als Code haben. Dann meckert Memcheck in der Zeile:
  test := BoolToStr(Sender.IsChild, true);

Ich glaube noch nicht ganz, das es an der Funktion BoolToStr liegt. Deshalb würde ich mich da nicht ganz drauf fixieren. Zu FastMM findest Du hier einige Einträge im Forum.

[jim_raynor]

Zitat von pertzschc:

Danke für den Tipp mit FastMM. Funktioniert das auch mit Delphi 7 und wo kann ich ein Tutorial dazu finden?

Ja, funktioniert viel besser als MemCheck.