pchar freigeben?

[mumu]

muss man einen pchar eigentlich freigeben? und wenn ja, wie?

ich hab hier ein programm, bei dem der Programmierer jeden lokalen pchar am Ende der procedure auf nil gesetzt hat:

Delphi-Quellcode:

temp: PChar;
begin
...
temp:= nil
end;

[JasonDX]

das setzen des Zeigers auf nil gibt keinen Speicher frei, damit kriegst du ein schönes Speicherleck. Das Gegenmittel heißt FreeMem, das dir den reservierten Speicher einer Variable freigibt ;)

greetz
Mike

[mumu]

Zitat:

Zitat von JasonDX

das setzen des Zeigers auf nil gibt keinen Speicher frei, damit kriegst du ein schönes Speicherleck. Das Gegenmittel heißt FreeMem, das dir den reservierten Speicher einer Variable freigibt ;)

greetz
Mike

jo das ist mir auch irgendwie klar. deshalb hab ich mich auch so gewundert... was der programmierer da macht.

ist FreeMem bei lokalen PCHars eigentlich nötig, oder macht delphi das nach ende der procedure selbst?

[mkinzler]

Da PChar nur eine Zeigertyp ist (Zeiger auf einen Char) ist ein Freemem eigentlich nicht nötig. Man muß u.U. aber den Speicher der Struktur freigeben auf welchen der pchar gesetzt wurde.

[mumu]

Zitat:

Zitat von mkinzler

Da PChar nur eine Zeigertyp ist (Zeiger auf einen Char) ist ein Freemem eigentlich nicht nötig. Man muß u.U. aber den Speicher der Struktur freigeben auf welchen der pchar gesetzt wurde.

jo genau, oki dann hat sich das erledigt. muss ich also nicht freigeben. das ich die strukturen freigeb, ist mir klar.

vielen dank

[ste_ett]

GetMem/FreeMem oder besser New/Dispose wird nur benötigt, wenn du z.B. PChars an Funktionen übergibst und diese den "Inhalt" des PChars verändern. :)

[mumu]

Zitat:

Zitat von ste_ett

GetMem/FreeMem oder besser New/Dispose wird nur benötigt, wenn du z.B. PChars an Funktionen übergibst und diese den "Inhalt" des PChars verändern. :)

hä? warum das?

[Sebastian R.]

Weil dann ein neues Pchar erzeugt wird.

[tommie-lie]

Ich fürchte hier herrscht Verwirrung über die Bedeutung von "PChar" und "C-String".
Eine Variable vom Typ PChar, vollkommen egal ob lokal oder global, muss nicht freigegeben werden. Ist die lokal, wird sie auf dem Stack abgelegt und beim Unrolling auch wieder davon entfernt, genauso wie alle lokalen Variablen. Globale Variablen haben ihren Speicherplatz im Image des Codes, sie existieren ohnehin über die gesamte Programmlaufzeit hinweg. In der Tat ist es gar nicht möglich, eine Variable wieder freizugeben. Habe ich eine Schleifenvariable i vom Typ Integer, die ich nach der Ausführung der Schleife nicht wieder benötige, ist es (praktisch) unmöglich, diese Variable i wieder aus dem Stack zu entfernen und den von ihr belegten Speicher wieder für andere Variablen zu benutzen. Bei einer Variable vom Typ PChar ist das nicht anders, ich kann den Speicherplatz (heute noch 4 Byte) nicht wieder freigeben.
Die 4 Byte hinter dem PChar können allerdings als Pointer interpretiert werden, der auf einen bestimmten Speicherbereich zeigt. Das wird in der Regel ein Block auf dem Heap sein. Diesen Block muss ich explizit reservieren (GetMem(), New(), HeapAlloc(), GlobalAlloc(), Konstruktor einer Klasse) und muss ihn daher genauso explizit wieder freigeben (FreeMem(), Dispose(), HeapFree(), GlobalFree(), Destruktor einer Klasse). Wenn ich also zunächst Speicher für meine PChar-Variable reserviere und anschließend einen String reinschreibe, muss ich den Speicher anschließend auch wieder freigeben, genauso wie ich ein Objekt durch einen Aufruf seines Destruktors zerstören muss (zumindest in Delphi).
Die Variable lediglich auf den Wert nil zu setzen ist sinnlos. Wenn ich den Speicher noch nicht freigegeben habe, verliere ich damit die Referenz auf den Speicher (der somit allokiert bleibt). Wenn ich den Speicher bereits freigegeben habe, benötige ich eine Zuweisung auf nil nicht mehr.
Da man PChars in der Regel auch zum Referenzieren von Speicherblöcken benutzt und nicht, weil sie bei den Variablen-Definitionen schick aussehen, muss man diese Speicherblöcke auch wieder freigeben.

Die Aussage von mkinzler:

Zitat:

Zitat von mkinzler

Da PChar nur eine Zeigertyp ist (Zeiger auf einen Char) ist ein Freemem eigentlich nicht nötig.

Ist in beiden möglichen Interpretationsfällen falsch:
Ein FreeMem() ist auf die Variable vom Typ PChar nicht anwendbar, es ist also nicht nicht nötig, sondern es ist gar nicht erst möglich.
Ein FreeMem() auf den Speicherbereich, den die Variable vom Typ PChar referenziert (FreeMem(blubb), wenn blubb vom Typ PChar ist), ist auf jeden Fall nötig, sofern diese Variable einen Speicherbereich allokiert, der zuvor angefordert wurde (also dann, wenn man tatsächlich etwas mit seiner Variable macht).
Besonders interessant wird es dann, wenn man eine Variable vom Typ PChar hat, die auf das erste Zeichen eines Pascal-Strings zeigt:

Delphi-Quellcode:

procedure DoSomething;
var
  s: String;
  c: PChar;
begin
  s := 'Hello, world';
  c := @s[1];
end;

Hier vermischt man Compiler-Magic (Pascal-Strings) mit gewöhnlichem handmade Code. Es wird (dynamisch auf dem Heap) Speicher für den Pascal-String "Hello, world" reserviert. Gleichzeitig zeigt aber c auf das erste Zeichen. Beim verlassen der Funktion wird nun automagisch der Speicher des Strings freigegeben und somit auch der Speicherbereich, auf den c zeigt. Ein zusätzlichen Freigeben von c wäre hier unangebracht und würde zu einem Fehler führen, wenn der Compiler den Speicher für den String ein zweites Mal freigeben möchte (EInvalidPointer dürfte die Exception sein).


HTH

[mumu]

vielen vielen dank für die ausführliche antwort !!!! :thumb:

aber eine frage hätte ich noch:

Delphi-Quellcode:

p_char: PChar;
begin
...
  p_char := nil;
  FreeMem(p_char);
end;

macht sowas sinn? wenn ich doch den p_char auf nil setz, dann kann ich doch den speichernbereich mit FreeMem nicht mehr freigeben, weil ich ja net weiß, wohin der p_char zeigt, oder?

// edit:
ahh hier steht ja die antwort, sorry :-)

Zitat:

Die Variable lediglich auf den Wert nil zu setzen ist sinnlos. Wenn ich den Speicher noch nicht freigegeben habe, verliere ich damit die Referenz auf den Speicher (der somit allokiert bleibt). Wenn ich den Speicher bereits freigegeben habe, benötige ich eine Zuweisung auf nil nicht mehr.
Da man PChars in der Regel auch zum Referenzieren von Speicherblöcken benutzt und nicht, weil sie bei den Variablen-Definitionen schick aussehen, muss man diese Speicherblöcke auch wieder freigeben.

[mumu]

Zitat:

Zitat von mumu

vielen vielen dank für die ausführliche antwort !!!! :thumb:

aber eine frage hätte ich noch:

Delphi-Quellcode:

p_char: PChar;
begin
...
  p_char := nil;
  FreeMem(p_char);
end;

macht sowas sinn? wenn ich doch den p_char auf nil setz, dann kann ich doch den speichernbereich mit FreeMem nicht mehr freigeben, weil ich ja net weiß, wohin der p_char zeigt, oder?

// edit:
ahh hier steht ja die antwort, sorry :-)

Zitat:

Die Variable lediglich auf den Wert nil zu setzen ist sinnlos. Wenn ich den Speicher noch nicht freigegeben habe, verliere ich damit die Referenz auf den Speicher (der somit allokiert bleibt). Wenn ich den Speicher bereits freigegeben habe, benötige ich eine Zuweisung auf nil nicht mehr.
Da man PChars in der Regel auch zum Referenzieren von Speicherblöcken benutzt und nicht, weil sie bei den Variablen-Definitionen schick aussehen, muss man diese Speicherblöcke auch wieder freigeben.

aber trotzdem nochmal die frage, damit ich mir auch 100 prozentig sicher bin:
folgendes in der reihenfolge kann eigentlich nie sinn machen, oder?
p_char := nil;
FreeMem(p_char);

weil ich schnall irgendwie net, warum mein vorgänger, dass bei jedem p_char gemacht hat?! Ich würd auf sowas eigentlich schon gar nicht kommen?!

[Luckie]

Dein Code wird eine AV auslösen, weil, wie Thomas erklärt hat, mit nil die Referenz gelöscht wird, aber das wird sie sowieso nach verlassen der lokalen Routine. Allein das FreeMem ist wichtig, wenn du Speicher mit GetMem reervierst, um den Speicher wieder frezugeben und aufzuräumen.

[mumu]

hi luckie,

nee eben nicht, da werden keine av's ausgelöst. das ist ja eben das komische?! und der verwendet des wirklich überall im code???

[Muetze1]

Ja, weil FreeMem() intelligent ist und einen NULL/NIL Parameter handeln kann - sprich: ihn ignoriert. Das geht gehört mit dem Funktionssyntax AllocMem() ReAllocMem(), wobei letztere auch Speicher freigeben und den Zeiger bei einer Grösse von 0 auf Nil setzen. Trotzdem kann bei Verwendung eines solchen Codes immer FreeMem() am Ende aufgerufen werden, damit bei eventuell nicht auf eine Grösse von 0 reduzierte Bereiche freigegeben werden.

[mumu]

Zitat:

Trotzdem kann bei Verwendung eines solchen Codes immer FreeMem() am Ende aufgerufen werden, damit bei eventuell nicht auf eine Grösse von 0 reduzierte Bereiche freigegeben werden.

hä? woher will der wissen, welche bereiche freigegeben werden müssen, wenn er ja nur nil übergeben bekommt?

wenn ich aber jetzt alles von

Delphi-Quellcode:

p_char: PChar; 
begin 
... 
  p_char := nil; 
  FreeMem(p_char); 
end;

in

Delphi-Quellcode:

p_char: PChar; 
begin 
... 
  FreeMem(p_char); 
end;

ändere, dann sollte es eigentlich keine probleme geben, oder?

[Muetze1]

Zitat:

Zitat von mumu

Zitat:

Trotzdem kann bei Verwendung eines solchen Codes immer FreeMem() am Ende aufgerufen werden, damit bei eventuell nicht auf eine Grösse von 0 reduzierte Bereiche freigegeben werden.

hä? woher will der wissen, welche bereiche freigegeben werden müssen, wenn er ja nur nil übergeben bekommt?

Wenn er NIL bekommt ist nix mehr freizugeben. Ist der übergebene Zeiger noch <> NIL, dann ist noch was freizugeben. Was ist daran denn so unverständlich?

Zitat:

Zitat von mumu

wenn ich aber jetzt alles von

Delphi-Quellcode:

p_char: PChar; 
begin 
... 
  p_char := nil; 
  FreeMem(p_char); 
end;

in

Delphi-Quellcode:

p_char: PChar; 
begin 
... 
  FreeMem(p_char); 
end;

ändere, dann sollte es eigentlich keine probleme geben, oder?

Ich weiss nicht wie du bei den "..." Bereich im Code den PChar belegst, aber von dem reinen hier zu sehenden Code bekommst du dadurch höchstwahrscheinlich AV's, da der PChar zufällige Werte enthält (da lokale Variable).

[tommie-lie]

Zitat:

Zitat von Muetze1

Ich weiss nicht wie du bei den "..." Bereich im Code den PChar belegst, aber von dem reinen hier zu sehenden Code bekommst du dadurch höchstwahrscheinlich AV's, da der PChar zufällige Werte enthält (da lokale Variable).

Wie ich oben schon schrob ist eigentlich davon auszuegehen, daß PChar-Variablen auch verwendet werden und nicht nur existieren, weil sie schön aussehen. Es gibt Ausnahmen (eine davon war oben von mir benanntes Pascal-String-Beispiel), aber in der Regel sollte man schon ein FreeMem() oder Dispose() auf den PChar durchführen.
Kurzum, um folgende Frage zu beantworten:

Zitat:

Zitat von mumu

woher will der wissen, welche bereiche freigegeben werden müssen, wenn er ja nur nil übergeben bekommt?

Kann er nicht, und genau das ist das Problem. Wenn FreeMem() einen Zeiger auf nil übergeben bekommt, passiert exakt "gar nichts". Wenn du einen gültigen Pointer auf nil setzt, weißt du anschließend nicht mehr, wo genau im Speicher der dazugehörige Speicherblock zeigt, du hast ja soeben deinen einzigen Zeiger auf diesen Block mit nil gefüllt. FreeMem() kann auch nicht hellsehen, es kann diesen "verwaisten" Speicherbereich auch nicht mehr finden und freigeben. Somit bleibt der Speicherbereich allokiert bis zum StNimmerleinstag, oder bis das Programm beendet wird und Windows den gesamten Adressbereich des Prozesses freigibt.

Zu deiner nil-Geschichte:
Vielleicht ist dir in einigen Quellcodes schon aufgefallen, daß Objekte nicht mit objekt.Free() freigegeben werden, sondern mit FreeAndNil(objekt). Free() setzt, ebenso wie FreeMem() den Pointer *nicht* auf nil, sondern lässt ihn auf dem alten Wert (irgendwo im Speicher) und gibt lediglich den freigegebenen Speicher frei. Da mit FreeAndNil() meine Objektreferenz nil wird, kann ich zu einem späteren Zeitpunkt feststellen, ob mein Objekt freigegeben ist bzw ob ich mit meiner Objektreferenz tatsächlich noch ein existierendes Objekt habe. Genauso kann man es mit PChars machen. Erst freigeben und nachher selber af nil setzen (und nur in dieser Reihenfolge!). Dann kannst du später mit einer if-Abfrage überprüfen ob der PChar noch gültig ist. Wenn du das in deinem gesamten Programm konsequent durchziehst, kann man pauschal die Aussage treffen: Alle PChars, die nicht nil sind, verweisen auf einen gültigen Speicherbereich. Solche Aussagen können sich irgendwann mal als praktisch erweisen.

Zitat:

Zitat von mumu

weil ich schnall irgendwie net, warum mein vorgänger, dass bei jedem p_char gemacht hat?!

Vielleicht Unwissen - wohl der Grund, warum er jetzt nur Vorgänger ist :mrgreen:
Es ist in dieser Reihenfolge jedenfalls falsch und unsinnig.

[mumu]

Zitat:

ich weiss nicht wie du bei den "..." Bereich im Code den PChar belegst, aber von dem reinen hier zu sehenden Code bekommst du dadurch höchstwahrscheinlich AV's, da der PChar zufällige Werte enthält (da lokale Variable).

ja es ist schon klar, natürlich wird davor mit GetMem Speicher angefordert.

Vielen vielen Dank Tommie-lie genau auf so eine klipp und klare antwort habe ich gehofft :-) :thumb: :thumb: :thumb:

[Muetze1]

Zitat:

Zitat von tommie-lie

Dann kannst du später mit einer if-Abfrage überprüfen ob der PChar noch gültig ist. Wenn du das in deinem gesamten Programm konsequent durchziehst, kann man pauschal die Aussage treffen: Alle PChars, die nicht nil sind, verweisen auf einen gültigen Speicherbereich. Solche Aussagen können sich irgendwann mal als praktisch erweisen.

Man sollte vllt. in dem Sinne noch darauf hinweisen, wenn ein lokaler AnsiString mit einem Typecast zu einem PChar gewandelt wird, weil dann wird der PChar mit verlassen der Procedure ungültig (mit dem AnsiString, auf den er halt zeigt). Dies ist in dem Falle zu beachten, dann kann man beim konsequenten zurücksetzen von deiner Aussage ausgehen. (PChar als Funktionsergebnis, etc)

Zitat:

Zitat von mumu

ja es ist schon klar, natürlich wird davor mit GetMem Speicher angefordert.

Da es aber viele Möglichkeiten gibt und es auch andere Speicherreservierungen als GetMem() gibt, ist nicht immer FreeMem() richtig, daher habe ich mich nicht zu der grundlegenden Aussage hinreissen lassen, dass FreeMem() richtig ist. Hättest du GetMem() in dem Kurz-Pseudo-Code mit hingeschrieben, hätte ich das bestätigt.

Man muss halt genau sein, sonst heisst es ein halbes Jahr später wieder: "Aber du hattest doch geschrieben ..." und man stellt mit Entsetzen fest, es war nicht eindeutig formuliert bzw. derjenige denkt nicht an das an was ich damals dachte...

[Flocke]

Wenn du den Speicher selbst mit GetMem holst, und wenn du es `ganz´ sauber machen willst, dann schreibe es so:

Delphi-Quellcode:

var
  p_char: PChar;
begin
  ...
  GetMem(p_char, n_char);
  try
    ...
  finally
    FreeMem(p_char);
  end;
end;

[tommie-lie]

Zitat:

Zitat von Muetze1

Man sollte vllt. in dem Sinne noch darauf hinweisen, wenn ein lokaler AnsiString mit einem Typecast zu einem PChar gewandelt wird, weil dann wird der PChar mit verlassen der Procedure ungültig

Jupp, darauf wurde ja hingewiesen.

Zitat:

Zitat von Muetze1

(PChar als Funktionsergebnis, etc)

Pointer auf lokale Variablen zurückgeben ist aus diesem Grund im Allgemeinen böhse[tm]. Das wird bei C++ dann lustig, wenn man sich auf dem Stack Objekte erzeugt und anschließend meint, mit Pointern darauf zu schießen ;-)

Zitat:

Zitat von Muetze1

Da es aber viele Möglichkeiten gibt und es auch andere Speicherreservierungen als GetMem() gibt

In diesem Sinne noch ein Hinweis zu diesem Beitrag: Es finden sich Klammern im Text, in denen einige (nicht alle) Möglichkeiten aufgezählt werden, wie man Speicher reservieren und wieder freigeben kann. Die Listen in diesen Klammern entsprechen sich. Die richtige Methode zum Freigeben eines mit GetMem() allokierten Blocks ist also FreeMem(), zu New() gehört Dispose() und so weiter.