Wie wichtig ist FREE?

[cyanroot]

Hallo,

ich wollte fragen, wie wichtig es ist, ein Textdokument in einer Memo nach dem Speichern mit free zu lösen? Braucht man das wenn 2 Leute gleichzeitig auf das Dokument speichernd zugreifen?

Danke.

[DeddyH]

Das Free hat nichts mit dem Speichern einer Datei zu tun, sondern mit dem Freigeben des für das Objekt angeforderten Speichers.

[cyanroot]

Und wann genau braucht man das?

[Sir Rufo]

Wenn du das Objekt nicht mehr benötigst.

Ist wie zu Hause mit dem Aufräumen ... man kann aber man muss nicht, allerdings hat es Vorteile ;)

Nicht Aufräumen -> kann zum Chaos führen (Messie)
Nicht FREE -> kann zum Speicherüberlauf führen

[DeddyH]

Du solltest angeforderten Speicher sobald wie möglich wieder freigeben. Ein Beispiel:

Delphi-Quellcode:

procedure TFormWuppdi.Tuwas;
var aList: TStringList;
begin
  aList := TStringList.Create;
  try
    //mach was mit der Liste
  finally
    aList.Free; //Liste auf jeden Fall freigeben
  end;
  //weiterer Code, bei dem die Liste nicht gebraucht wird
end;

[cyanroot]

Macht das SInn, wenn auf diese Datei alle 2 Minuten zugegriffen wird? Sollta man sie dann trotzdem immer Freigeben?

[Weazy]

Solange das Objekt benötigt wird muss du es nicht immer wieder freigeben und neu erzeugen. Du musst allerdings sicher sein das Objekt irgendwann wieder freigegeben wird! Wenn du z.B eine StringListe hast die du immer wieder brauchst könntest du sie beim starten des programmes erzeugen und erst am ende wieder freigeben. Vielleicht ne dämliche Frage, aber wenn ich ein programm mit dem taskmanager abschiesse wird der speicher aller objekte dieses programmes doch freigegeben?

[Sir Rufo]

Primär benötigst du erstmal etwas um diese konkurrierenden Schreibzugriffe zu steuern ... !

Um in eine Textdatei etwas zu speichern verfährst du am besten so:

Delphi-Quellcode:

var
  MeineDatei : Text;
begin
  AssignFile( MeineDatei, 'C:\Daten\MeineDatei.txt' );
  AppendFile( MeineDatei );
  WriteLn( MeineDatei, 'Ich will auch mal' );
  CloseFile( MeineDatei );
end;

Bei so einem Zugriff habe ich nix mit einem Objekt zu tun, also auch nix mit FREE am Hut.
Hier wird jetzt die Datei zum Anhängen geöffnet und nach dem Schreiben sofort wieder geschlossen.

Was noch nicht passiert, ist die Abfrage, ob auf diese Datei überhaupt schreibend zugegriffen werden kann, dieses müsstest du noch einbauen. Wie man das macht, findest du eigentlich auch hier im Forum.

cu

Oliver

[Sir Rufo]

Zitat:

Zitat von Weazy

Vielleicht ne dämliche Frage, aber wenn ich ein programm mit dem taskmanager abschiesse wird der speicher aller objekte dieses programmes doch freigegeben?

Ja, sollte eigentlich passieren und passiert wohl auch zu 99%. Wenn ich das machen muss, dann hat aber das Programm verm. eine Macke und sollte daraufhin korrigiert werden, dann brauche ich auch nix mehr abschießen ;)

cu

Oliver

[taaktaak]

ääähhhhhh (verwirrt) -
kann es sein, dass das "file", das bei "append" zu viel ist, bei "text" fehlt??

[Sir Rufo]

ja, ja :mrgreen: habe ich nur so auf die Schnelle zusammengetippt

[DeddyH]

Das sag ich in solchen Fällen auch immer :mrgreen:

[gsh]

hier noch ein kleiner Tipp. Schreibe immer folgende Zeile in der Projektdatei hinzu:

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := true; <-- Diese hier
Application.Initialize;
Application.CreateForm(TForm1, Form1);
Application.Run;

Damit bekommst du beim Programm ende ein kleine Meldung angezeigt wenn du mal vergessen hast etwas freizugeben.

Zitat:

Zitat von Weazy

Vielleicht ne dämliche Frage, aber wenn ich ein programm mit dem taskmanager abschiesse wird der speicher aller objekte dieses programmes doch freigegeben?

Windows gibt beim Programm ende alles frei (auch wenn die Datei abgeschossen wird). Aber schöner ist es wenn man es selber macht.

[Dezipaitor]

Free ist solange egal, bis in 32bit Anwendungen der 2GB Speicher reicht. Windows gibt am Ende eh den Anwendungsspeicher frei.
Wenn deine Anwendung auf 64bit läuft ist das fast egal. Da ist der verbaute Speicher die Grenze.

[gsh]

Zitat:

Zitat von Dezipaitor

Free ist solange egal, bis in 32bit Anwendungen der 2GB Speicher reicht. Windows gibt am Ende eh den Anwendungsspeicher frei.
Wenn deine Anwendung auf 64bit läuft ist das fast egal. Da ist der verbaute Speicher die Grenze.

so würde ich das nicht sagen .. stell dir vor jede Anwendung würde fast 2GB Speicher verbrauchen. Also ich weiß nicht wie es dir geht aber ich hab keine 100GB RAM in meinem Computer :wink:

[Sir Rufo]

Zitat:

Zitat von gsh

Zitat:

Zitat von Dezipaitor

Free ist solange egal, bis in 32bit Anwendungen der 2GB Speicher reicht. Windows gibt am Ende eh den Anwendungsspeicher frei.
Wenn deine Anwendung auf 64bit läuft ist das fast egal. Da ist der verbaute Speicher die Grenze.

so würde ich das nicht sagen .. stell dir vor jede Anwendung würde fast 2GB Speicher verbrauchen. Also ich weiß nicht wie es dir geht aber ich hab keine 100GB RAM in meinem Computer :wink:

Dann würde ich aber mal schnell aufrüsten ... dann kann man sich das Free auch sparen, wer weiß wofür man die ganzen Objekte noch brauchen kann ... vielleicht eine Gebraucht-Objekt-Börse errichten :mrgreen:

[Mao]

Das Betriebssystem hat bei 64-Bit-Adressierung allerdings die Möglichkeit, eine ganze Menge auf die Platte auszulagern. Wenn die Platte zulässt, weit mehr als nur die 100GB.

[Weazy]

das wird aber extrem langsam wenn du nicht gerade ein 1000 euro teuren flash speicher hast :stupid:

[gsh]

Zitat:

Zitat von Weazy

das wird aber extrem langsam wenn du nicht gerade ein 1000 euro teuren flash speicher hast :stupid:

naja egal Hauptsache man kann die Objekte wiederverwenden ... recycling ist ja heutzutage sehr wichtig :mrgreen:

[Luckie]

Zitat:

Zitat von gsh

so würde ich das nicht sagen .. stell dir vor jede Anwendung würde fast 2GB Speicher verbrauchen. Also ich weiß nicht wie es dir geht aber ich hab keine 100GB RAM in meinem Computer :wink:

Das macht nichts. Im Gegensatz zu DOS hat Windows ja einen virtuellen Speicher. Da hat jeder Prozess einen entsprechend großen Adressraum. Unter 32-Bit sind eben 4 GB bzw. nutzbare 2 GB. Die tatsächliche Größe des Arbeitsspeichrs spielt da erstmal keine Rolle, weil dann eben in die Auslagerungsdatei ausgelagert wird. Die Größe des Arbeitsspeichers spielt dann eher bei der Performance eine Rolle. Je größer der Arbeitsspeicher ist, desto weniger muss ausgelagert werden und Lese- bzw. Schreibzugriffe auf die Festplatte sind eben (noch) sehr langsam.

Nichtsdestotrotz ist der Adressraum pro Prozess eben begrenzt und man sollte schon dafür sorgen, dass nicht mehr benötigter Speicher wieder freigegeben wird. Es geht ja nicht immer nur um den absoluten frien Speicher, sondern auch um zusammenhängenden Speicher. Wenn ich ein dynamisches Array initialisiere und nicht genug zusammenhängender Speicher alloziiert werden kann, ist auch Ende. Und da ist es egal, wie groß der Adressraum ist. Wenn bei 64-Bit der Speicher ungünstig belegt wird, kann es auch da passieren, dass nicht genug zusammenhänmgender Speicher zur Verfügung steht. Ausserdem ist es sauberer Stil, seinen Speicher wieder selbst frei zu geben. Will man sich darum nicht kümmern müssen, dann muss man eine Sprache benutzen, die eine Garbagecollection besitzt und sich selber um das Freigeben kümmert.

Aber um auf die Ausgangsfrage zurückzukommen eine Gegenfrage: "Wie wichtig ist es den Müllereimer zu leeren?"