Sämtlichen Speicher freigeben?

[MCXSC]

Hallo!

Eine kleine (dämliche :D) Frage: Gibt es irgendetwas (Codezeile, Funktion, Unit/Kompo), die sämtlichen geschriebenen Speicher wieder in Windows löscht/freigibt (z.B. bei Programmende)?

Danke im vorraus,
MCXSC

[turboPASCAL]

Nein, eine allgemeine Lösung dafür gibt es nicht. Du musst du schon selbst dafür sorgen
das der Speicher den Du belegst auch wieder frei gibst.

Was für ein Problem gibt es denn genau ?

[Robert Marquardt]

Wenn sich dein Programm beendet, dann wird saemtlicher Speicher von alleine freigegeben.

[gsh]

Zitat:

Zitat von Robert Marquardt

Wenn sich dein Programm beendet, dann wird saemtlicher Speicher von alleine freigegeben.

ja des schon aber sowas ist eigentlich sehr unschön

@MCXSC: du solltest immer schauen des wenn du was freigibst des du es auch wieder freigibst. Sonst gibt es gleich mal ein speicherleak.

Am besten du fügst an deine Projekt immer folgende Codezeile ein:

Delphi-Quellcode:

begin
  ReportMemoryLeaksOnShutdown := true;  //<- diese Zeile hier
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Dann siehst du gleich wenn du ein Speicherleak gemacht hast

[Bernhard Geyer]

Zitat:

Zitat von gsh

Zitat:

Zitat von Robert Marquardt

Wenn sich dein Programm beendet, dann wird saemtlicher Speicher von alleine freigegeben.

ja des schon aber sowas ist eigentlich sehr unschön

Ist ja nur der Notanker von Windows damit nicht wie unter Win16 einzelnen Prozesse einfach Windows vollmüllen können.

Und im Release-Build will ich auch den Endkunden nicht mit Fehlerreports belästigen.

[MCXSC]

Zitat:

Zitat von gsh

@MCXSC: du solltest immer schauen des wenn du was freigibst des du es auch wieder freigibst. Sonst gibt es gleich mal ein speicherleak.

Am besten du fügst an deine Projekt immer folgende Codezeile ein:

Delphi-Quellcode:

begin
  ReportMemoryLeaksOnShutdown := true;  //<- diese Zeile hier
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Da bekomm ich die Meldung "Undefinierter Bezeichner".

Kann ich das denn auch noch nach Beenden sehen? Weil ich habe das Problem, dass Windows immer nach Schließen meines Programmes ausschlägt und ich denke mal, es hängt irgendwie mit dem VST zusammen...

[Axxus]

Bei .Net gibt es die sog. Garbage Collection, die meines Wissens nach den gesammten Arbeitsspeicher generell "aufräumt". Damit ist gemeint das sie Automatisch erkennt welche resourcen nicht mehr gebraucht werden und diese dann aus dem Arbeitsspeicer löscht. Sie erkennt sogar wenn 2 Prozesse nur noch gegenseitig aufeinander zugreifen.

Wie genau man die impleniert weiß ich nicht müsstest du mal googeln, allerdings solltest du mit dem einbau in dein Programm vorsichtig sein, da die Garbage Collection ziemlich viel Prozessorleistung in Anspruch nimmt...

Gruß

Axxus

[MCXSC]

Zitat:

Zitat von Axxus

Bei .Net gibt es die sog. Garbage Collection

Geht sich aber ums Win.32^^

[Bernhard Geyer]

Zitat:

Zitat von MCXSC

Da bekomm ich die Meldung "Undefinierter Bezeichner".

Der obige Code geht erst ab Delphi 2006, da dort FastMM verwendet wird. Für D7 mußt du dir FastMM4 von Sourceforge holen.[/quote]

Zitat:

Zitat von Axxus

Damit ist gemeint das sie Automatisch erkennt welche resourcen nicht mehr gebraucht werden und diese dann aus dem Arbeitsspeicer löscht.

Ressourcen wie GDI-Handles, File-Handles werden nicht freigegeben. So intelligent ist auch der .NET GC nicht.

Zitat:

Zitat von Axxus

Sie erkennt sogar wenn 2 Prozesse nur noch gegenseitig aufeinander zugreifen.

Wirklich? Ich konnte solche Fehlerfälle unter .NET 1.0 astrein provozieren.

Zitat:

Zitat von Axxus

Wie genau man die impleniert weiß ich nicht müsstest du mal googeln, allerdings solltest du mit dem einbau in dein Programm vorsichtig sein, da die Garbage Collection ziemlich viel Prozessorleistung in Anspruch nimmt...

"Einbauen" kann man sowas nicht. Entweder man hat mit Java oder .NET eine managed Umgebung und hat damit ohne wenn und aber einen GC oder man hat keinen.

[DMW]

Zitat:

Zitat von Bernhard Geyer

"Einbauen" kann man sowas nicht.

Doch, das kann man, in C++ z.B. den hier.

[Axxus]

Wie gesagt ich hab noch nicht damit gearbeitet, sondern nur davon gehört. bin mir aber relativ sicher, dass die GC auch seit neustem Prozesse erkennt die nur noch auf sich selber zugreifen ( es gibt ja inzwischen schon .Net Framework 3.0, kannn sein, dass der das bei 1.0 noch nicht gemacht hat)

Gruß

Axxus

[phXql]

Zitat:

Zitat von DMW

Zitat:

Zitat von Bernhard Geyer

"Einbauen" kann man sowas nicht.

Doch, das kann man, in C++ z.B. den hier.

Wie soll sowas gehen? Ich kann in C++ doch die Pointeradressen inkrementieren und so an Speicher rankommen, wo keine Referenzen mehr drauf sind.

[grenzgaenger]

über einen eigenen speichermanager, über den sämtliche memory anforderungen und freigaben gehen. sonst keine change. aber das ist ja auch mit delphi möglich ... ;-)

[Bernhard Geyer]

Zitat:

Zitat von phXql

Zitat:

Zitat von DMW

Zitat:

Zitat von Bernhard Geyer

"Einbauen" kann man sowas nicht.

Doch, das kann man, in C++ z.B. den hier.

Wie soll sowas gehen? Ich kann in C++ doch die Pointeradressen inkrementieren und so an Speicher rankommen, wo keine Referenzen mehr drauf sind.

Ganu das Problem sehe ich bei C++ auch das man sehr viel Mist mit der Pointerrei machen kann. Nicht umsonst wurden einige C++Features in der C++-Implementierung bei .NET verboten.

[grenzgaenger]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von phXql

Zitat:

Zitat von DMW

Zitat:

Zitat von Bernhard Geyer

"Einbauen" kann man sowas nicht.

Doch, das kann man, in C++ z.B. den hier.

Wie soll sowas gehen? Ich kann in C++ doch die Pointeradressen inkrementieren und so an Speicher rankommen, wo keine Referenzen mehr drauf sind.

Ganu das Problem sehe ich bei C++ auch das man sehr viel Mist mit der Pointerrei machen kann. Nicht umsonst wurden einige C++Features in der C++-Implementierung bei .NET verboten.

:lol: aber das geht doch auch mit pascal :-) .

[Bernhard Geyer]

Zitat:

Zitat von grenzgaenger

Genauu das Problem sehe ich bei C++ auch das man sehr viel Mist mit der Pointerrei machen kann. Nicht umsonst wurden einige C++Features in der C++-Implementierung bei .NET verboten.

:lol: aber das geht doch auch mit pascal :-) .[/quote]
Das stimmt zwar, aber wenn du "normalen" Pascal und C++-Code vergleichst wird bei C++-Code die Prozentzahl der Quellzeilen die einem GC probleme bereiten höher sein, sprich: Es wird schwieriger seinen einen Code unter C++ "GC-Kompatible" zu gestalten.

[grenzgaenger]

da hast du recht. da in pascal der compiler einfach mehr prüft..., wohingegen in C/C++ die Freiheiten GROSS geschrieben werden... ;-)

grüsse und noch 'n schönen abend
GG