Free+nil vs. FreeAndNil / Diskussion vs. Tutorial

Delphi-Laie · Verfasst: Mo 04.05.15 21:08

Moderiert von Narses: Abgetrennt von hier: [Tutorial] Game of Life

Erst nil setzen, dann freigeben (FeldShape)!

Martok · Verfasst: Mo 04.05.15 21:27

Delphi-Laie hat folgendes geschrieben :

Erst nil setzen, dann freigeben (FeldShape)!

Wenn, dann FreeAndNil nehmen. Ist aber weniger explizit (also anfängerfreundlich) darin was es tut, deswegen hab ich das bisher noch nicht eingeworfen...

_________________
"The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."

Delphi-Laie · Verfasst: Di 05.05.15 09:29

Martok hat folgendes geschrieben :

Delphi-Laie hat folgendes geschrieben :

Erst nil setzen, dann freigeben (FeldShape)!

Wenn, dann FreeAndNil nehmen. Ist aber weniger explizit (also anfängerfreundlich) darin was es tut, deswegen hab ich das bisher noch nicht eingeworfen...

Das ist Ansichtssache.

Anfängerfreundlich i.S. schneller Erfolge ist es gewiß.

Anfängerfreundlich i.S. des Lernens aber eher nicht. Denn so erfährt Nini nicht, daß mit Free ein Objekt zerstört wird und seine von ihm belegten Ressourcen (vornehmlich Speicher) wieder freigegeben werden, sodaß eine anschließende Wertzuweisung bestenfalls sinnlos ist, m.E. aber ziemlich sicher in eine Fehlermeldung mündet. Allerdings hat Nini schon genug zu lernen....

Narses · Verfasst: Di 05.05.15 20:41

Moin!

Leider muss ich erneut moderierend eingreifen, denn der Quellthread ist - wie bereits mehrfach an verschiedenen Stellen erläutert - keine Diskussion über das Thema GoL oder dessen möglichst optimale Implementation. Wir wollen hier vielmehr (neu für die EE - ja, wir entwickeln uns weiter!

) begleitetes Lernen (oder auch "Tutorial", wie der Angelsachse sagt) ausprobieren. :idea:

Da es in den extrahierten Beiträgen im Wesentlichen um einen weiteren Diskussionfaden geht, der vom eigentlichen Zweck des Threads ablenkt, habe ich diese hier hin ausgelagert. In diesem Thread können wir gerne und ausführlich weiter über das Thema diskutieren.

Was ich auch gleich aufgreifen möchte: user profile icon

Delphi-Laie, dein Vorschlag ist IMHO fachlich falsch, denn der Code, auf den sich dein Hinweis zur Ausführungsreihenfolge bezieht, ist folgender:

markieren

Delphi-Quelltext

1:
2:
3:
4:

if Assigned(FeldShape[x,y]) then begin
  FeldShape[x,y].Free;
  FeldShape[x,y] := nil;
end;

Wenn du hier erst nil zuweist und dann freigeben willst, wird das nicht funktionieren (oder besser noch eine Exception produzieren), weil du nämlich die Referenz zur Instanz auf dem Heap verloren hast und diese folglich nicht mehr freigeben kannst. :shock:

Ich möchte die Gelegenheit nutzen, nochmal ein paar grundsätzliche Sachen zu dem Gesamt-Thema zu sagen:

Der Nini-Thread IST KEINE DISKUSSION, deshalb werden wir dort auch nicht über die Sinnhaftig- oder -losigkeit irgendwelcher speziellen Teilaspekte diskutieren. Alles, was keinen konstruktiven Beitrag zu dem aktuell behandelten (Teil-)Thema darstellt, wird auch weiterhin ausgelagert werden. Dort wird nicht diskutiert, sondern beim Lernen begleitet. Folglich ist es gar nicht das Ziel, eine optimale Lösung zu erarbeiten, überhaupt eine ((möglichst) selbstständige) Lösung reicht bereits völlig aus. Das mag der Tradition eines Diskussionforums möglichweise auf den ersten Blick entgegensprechen, aber wenn wir uns nicht weiterentwickeln, dann bleiben wir stehen oder noch schlimmer, entwickeln uns sogar zurück.

Da es hier Teilnehmer mit Vorlieben für Analogien gibt: Es ist zwecklos darüber zu diskutieren, mit welchem Köder man am besten Forellen fängt, wenn der Mensch, mit dem man (vermeintlich) diskutiert gar nicht weiß, was eine Angel ist. Und genau genommen ist es sogar egal, dass es um eine Angel geht, es könnte auch ein Schrank oder eine Obstschale sein, denn es geht um den Umgang mit dem Werkzeug, nicht um das Ergebnis. :idea:

Und Leute, mal ehrlich: in Zeiten von vollautomatischen Fischfangflotten mit Grundschleppnetzen, die auch noch das kleinste Lebewesen zu Surimi verarbeiten - wir reden hier darüber eine ANGEL zu bauen, da wird es sicher keine Rolle spielen, ob man zum Schleifen der Rute 100er oder 200er Schleifpapier nimmt.

Genau genommen gehört dieser Absatz hier zwar in Popovs Thread zum Thema "Wie man GoL zu programmieren hat", aber ich will das jetzt auch nicht wild verteilen. Es scheint ja nicht naheliegend zu sein, also der Vollständigkeit halber auch noch die Begründung, warum ein Shape (für den Anfang und unter dem Aspekt des Lernens der Sprache) gar keine so schlechte Idee ist. In der abstrakten Vorstellung des GoL sind Zellen die Atome der Welt. Ein Shape repräsentiert eine Zelle, es hat eine Ausdehnung und eine "Farbe". Beim GoL geht es um Zellen und wie diese sich gegenseitig beeinflussen. Deshalb ist es für Anfänger durchaus naheliegend diese Darstellungsform zu wählen (was Nini übrigens ganz freiwillig auch getan hat). Erst wenn man mit den Fischfangflotten im Hinterkopf an die Sache rangeht, dann ist ein Shape natürlich komplett daneben, keine Frage. Aber, scheint auf dem Weg verloren gegangen zu sein: Nini möchte nur zufällig eine Angel bauen, eigentlich findet sie die Arbeit mit dem Werkzeug interessant...

Diskussionsforen scheinen nach Ansicht einiger hier Anwesender dazu da zu sein, jedes noch so kleine Thema so lange zu zerreden, bis jeder noch halbwegs interessierte Mitleser angesichts des Diskussionsmatschs angewiedert das Browserfenster schließt. Wo wir schonmal dabei sind, seien wir doch nochmal ganz ehrlich zu uns selbst: hier ist doch eh schon nix mehr los, und wenn wir jetzt auch noch anfangen, die paar Fragesteller und Lernwilligen zu Tode zu diskutieren, dann können wir hier auch gleich die Tore schließen, dann haben wir uns selbst überlebt. Und wenn das auch noch auf einem ganz anderen Niveau stattfindet, so dass der eigentliche Fragesteller gar nicht folgen kann, dann ist zumindest unsere (EE-Team) Grenze erreicht. Wenn hier keine Moderation notwendig ist, wo dann. (das ist eine rhetorische Frage [zu erkennen am fehlenden Fragezeichen], auf die wir keine Antwort erwarten - nur zur Sicherheit :roll:

)

Wir werden im Team über die Erweiterung bzw. Anpassung der Regeln diskutieren, so dass eine Situation wie aktuell vorliegend, auch durch offizielle Regelungen gestützt wird (was ich ja eigentlich gehofft hatte, vermeiden zu können :eyes:

naja, scheint nicht anders zu gehen) und dann eine Lösung vorstellen.

im Namen des EE-Teams
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

Delphi-Laie · Verfasst: Di 05.05.15 21:00

OOP ist das letzte, worüber ich mich streite, mangels Kompetenz. Daß man allerdings einem freigegebenen, also "destruierten" Objekt nachträglich noch einen Wert, und sei es nur ein schnödes nil, zuweisen kann, ist mir neu und leuchtet mir auch nicht ein.

Das Thema zu zerreden oder kaputtzudiskutieren war sicher weder Popovs noch meine Absicht. Hilfe(stellung) kann nicht immer optimal sein und ist manchmal trotz gutem Willen sogar fehlerhaft.

Ich rege an - um Mißverständnisse, Irritationen und ggf. sogar das Gefühl, verbannt und vor den Kopf gestoßen zu werden zu vermeiden - Lehr-/Lerngespräche, die keine Diskussionen werden sollen, so früh wie möglich als solche zu kennzeichnen und ggf. sogar mit gesondert restriktiven Schreibrechten zu versehen.

Narses · Verfasst: Di 05.05.15 22:23

Moin!

Delphi-Laie hat folgendes geschrieben :

Daß man allerdings einem freigegebenen, also "destruierten" Objekt nachträglich noch einen Wert, und sei es nur ein schnödes nil, zuweisen kann, ist mir neu und leuchtet mir auch nicht ein.

Gemach, FeldShape[x,y] ist kein Objekt, sondern tatsächlich nur ein Zeiger auf das eigentliche Objekt (den Speicherblock) auf dem Heap! :idea:

Wenn du also diesen Zeiger durch Beschreiben mit nil "entfernst", dann ist der Speicherblock auf dem Heap immer noch als belegt gekennzeichnet (das Objekt "existiert" noch), nur der Zeiger ist weg ("leer"). Deshalb erst mit .Free freigeben und dann den (jetzt auf ein ungültiges/freigegebenes Objekt zeigenden) Zeiger auf nil setzen.

Delphi-Laie hat folgendes geschrieben :

Ich rege an - um Mißverständnisse, Irritationen und ggf. sogar das Gefühl, verbannt und vor den Kopf gestoßen zu werden zu vermeiden - Lehr-/Lerngespräche, die keine Diskussionen werden sollen, so früh wie möglich als solche zu kennzeichnen und ggf. sogar mit gesondert restriktiven Schreibrechten zu versehen.

Wir werden das im Hinterkopf behalten.

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

jaenicke · Verfasst: Di 05.05.15 22:48

Delphi-Laie hat folgendes geschrieben :

Daß man allerdings einem freigegebenen, also "destruierten" Objekt nachträglich noch einen Wert, und sei es nur ein schnödes nil, zuweisen kann, ist mir neu und leuchtet mir auch nicht ein.

Du weist den Wert nil ja nicht "dem freigegebenen Objekt" zu, sondern der Variable, die eine Referenz, sprich einen Pointer, auf die Speicherstelle des Objekts enthält.

Der Unterschied zwischen selbst Free aufrufen und dann auf nil setzen und FreeAndNil ist, dass FreeAndNil auch bei Exceptions bei der Freigabe des Objekts die Referenzvariable auf nil setzt. Dadurch werden spätere Prüfungen mit Assigned bzw. direkt auf nil immer funktionieren, auch wenn es bei der Freigabe des Objekts einen Fehler gab.

Ein Fallstrick bei Verwendung von FreeAndNil ist, dass es einen beliebigen Typ als Paramter akzeptiert, auch ein Interface, und das dann auf TObject castet um es freizugeben. (Das geht leider nicht anders, da man einem typisierten var-Parameter keinen Nachfahren des angegebenen Typs, sprich in dem Fall wäre es ja TObject, übergeben könnte.)
Wenn man aber nun von Objekten auf Interfaces umstellt, läuft das FreeAndNil auf das Interface durch den Compiler, wenn man es vergisst zu entfernen, aber es knallt dann später im Programm.

Delphi-Laie · Ehemaliges Mitglied Erhaltene Danke: 1

Delphi-Laie hat folgendes geschrieben :

OOP ist das letzte, worüber ich mich streite, mangels Kompetenz. Daß man allerdings einem freigegebenen, also "destruierten" Objekt nachträglich noch einen Wert, und sei es nur ein schnödes nil, zuweisen kann, ist mir neu und leuchtet mir auch nicht ein.

Es ist aber schon nachvollziehbar, daß man einen Zeiger entfernt, wenn das, wohin er zeigt, nicht mehr existiert, oder? Im Grunde weist du ja nicht dem Objekt einen Wert zu, denn die Variable ist nicht das Objekt, sondern lediglich der Zeiger auf das Objekt – das nun nach Free nicht mehr existiert. Und du weist mit Nil auch dem Zeiger keinen Wert zu, sondern entfernst damit den Wert, den der Zeiger zuvor enthielt. An Nil ist übrigens genauso wenig oder viel schnöde (nichtswürdig, erbärmlich, verachtenswert) wie an einem Wert, der auf eine Speicherstelle zeigt, an der ein Objekt beginnt.

Popov · Verfasst: Mi 06.05.15 14:00

Ohne mir nun alles durchzulesen, vielleicht meine Meinung zu Free und Nil oder FreeAndNil.

Es gibt gelegentlich Unsitten beim Programmieren, FreeAndNil ist eine davon. Sie schadet nicht, womit es keinen Grund gibt sie zu bekämpfen. Aber sie nützt in 99,99% aller Fälle nichts. Im Grunde reicht Free, ein Nil braucht man nur in Ausnahmefällen. Einem Anfänger FreeAndNil zu verkaufen müsste deshalb bestraft werden, denn es verwirrt nur. Der Anfänger glaubt es muss so sein und setzt es in Zukunft selbst ein, ohne den Sinn zu kennen.

Aussage #1: Um ein Objekt freizugeben reicht nur ein Free!

Beispiel 1:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:

var
  sl: TStringList;
begin
  sl := TStringList.Create;
  try
    sl.CommaText := 'Mo,Di,Mi,Do,Fr,Sa,So';
    ShowMessage(sl.Text);
  finally
    sl.Free;
  end;
end;

Es macht keinen Sinn sl hinterher noch zu nilen. Wozu? Und FreeAndNil sind Free mit darauf folgendem Nil. Nur brauchen tut man es nicht.

Nun könnte man sagen: "ja, aber manchmal ist es nützlich, als bauen wir es ein. Schaden tut es ja nicht. Vielleicht kommt die Situation vor wo man es braucht, dann ist es da." Ok, dann muss man sich aber auch die Bemerkung gefallen lassen, hirnlos zu programmieren in der Hoffnung, dass es schon funktionieren wird, da man an einer anderen Stelle vorsichtshalber ein Nil gesetzt hat. In dem Fall funktioniert der geschriebene Code also nur zufällig. Mal ein Beispiel...

Beispiel 2:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

var
  Button: TButton;
begin
  Button := TButton(FindComponent('Button1'));

  if Button <> nil then
    ShowMessage(Button.Name);
end;

FindComponent gibt Nil zurück wenn Komponente nicht gefunden wird. Somit ist Nil eine Information. In dem Fall wird Nil als Information mitgeschickt um mitzuteilen ob die Komponente gefunden wurde oder nicht. Weiter...

Beispiel 3:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:

var
  Button: TButton;
begin
  Button := TButton(FindComponent('Button1'));

  Button.Free;
  Button := nil; //Ohne Nil wird versucht auf ein freigegebenes Objekt zuzugreifen

  if Button <> nil then
    ShowMessage(Button.Name);
end;

Hier wird Button1 zuerst gefunden und zugewiesen, dann aber sofort mit Free freigegeben. In der Regel muss auf Free nichts folgen, also keine Nil Zuweisung. In dem Beispiel aber wird im weiteren Code-Verlauf auf Button1 zugegriffen. Ein Free alleine reicht hier also nicht aus, denn Free gibt nur das Objekt frei, kümmert sich aber nicht um die Variable Button. Die hat immer noch die alte Adresse auf das Objekt gespeichert. In der Regel, also in 99,99% aller Fälle, ist das unwichtig, denn gibt man ein Objekt frei, nutzt man später auch die Variable nicht mehr. Hier in dem oberen Beispiel ist es aber ausnahmsweise wichtig. Denn hier ist Nil eine Information. Denn hier wird auf Nil geprüft, also müssen wir auch Nil setzten.

Aussage #2: Nil allein bringt nichts.

Beispiel 4:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:

var
  Button: TButton;
begin
  Button := TButton(FindComponent('Button1'));

  Button.Free;
  Button := nil;

  ShowMessage(Button.Name); //Hier kracht es trotz Nil
end;

Nil oder meinetwegen FreeAndNil sind Dreck wert wenn man nicht explizit auf Nil prüft. Das bedeutet aber auch, dass wenn man auf Nil prüft, man auch bewusst Nil setzten kann. Ein wahlloses verteilen von FreeAndNil (weil es alle so machen) ist somit Quatsch. Vor allem Anfänger verwirrt es, weil es die falsch Info vermittelt. Ein Free ist notwendig, weil damit das Objekt freigegeben wird, also den Speicher. Das Nil ist nur für den seltenen Fall nötig, dass es eine Teilung im Code gibt und ein Objekt an einer Stelle u. U. freigegeben wird, man aber an einer anderen Stelle noch damit arbeiten möchte. Aber Beispiel 4 zeigt, dass Nil alleine nichts bringt, wenn man nicht bewusst auf Nil prüft. Und wenn man bewusst prüft, dann kann man ein Objekt an der Stelle, wo man es u. U. vorher schon freigibt, auch nilen.

Aussage #3: FreeAndNil ist unnötig. Wer auf Nil prüft, kann auch Nil bewusst setzen.

_________________
Popov

jaenicke · Verfasst: Mi 06.05.15 14:23

Popov hat folgendes geschrieben :

Aussage #2: FreeAndNil ist unnötig. Wer auf Nil prüft, kann auch Nil bewusst setzen.

Du hast dir offenbar den Quelltext von FreeAndNil nicht angeschaut. Das macht eben nicht nur das, wie ich oben schon schrieb, sondern setzt das nil auch, wenn bei der Freigabe eine Exception auftritt.
Warum sollte man stattdessen überall selbst ein try..finally oder try..except einbauen? Das bläht den Quelltext unnötig auf, zumal sich fast jeder spätere Leser dann über den Grund wundern würde warum man nicht einfach FreeAndNil benutzt hat.

Ein anderer Aspekt ist, dass ein FreeAndNil dafür sorgt, dass es bei einer späteren erneuten Freigabe keinen Fehler gibt und bei späterer Benutzung eine Zugriffsverletzung an Adresse 0 passiert. Ohne kann es passieren, dass ein solcher Fehler verschleppt wird und nicht so schnell auffällt. Natürlich gibt es auch FastMM um solche Probleme zu finden.

Nichtsdestotrotz würde ich jetzt nicht unbedingt sagen jeder soll es überall setzen. Ich würde aber auch niemandem sagen er soll es nicht benutzen.

Das größere Problem ist aber eben die Umstellung auf Interfaces. Und das ist im Gegensatz zu einem einfachen "man braucht es nicht" ein echtes Problem.

// EDIT:
@ user profile icon

FaTaLGuiLLoTiNe:
Ja, ist natürlich richtig. Da habe ich anders geschrieben als gedacht. ;-)

Popov · Verfasst: Mi 06.05.15 15:34

Sorry wegen der Umnummerierung der Aussagen, aber ich hab eine beim Schreiben übersehen.

Zitat:

Du hast dir offenbar den Quelltext von FreeAndNil nicht angeschaut.

Ja, ist schon länger her, aber wie gesagt, ich nutze es nicht.

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

procedure FreeAndNil(var Obj);
var
  Temp: TObject;
begin
  Temp := TObject(Obj);
  Pointer(Obj) := nil;
  Temp.Free;
end;

Ich behaupte nicht ein toller Programmierer zu sein, aber ich stehe auf dem Standpunkt, nur das Nötigste in den Code einzubauen. Als ich 16 war, konnte ich mich selbst nach Monaten gut daran erinnern wieso ich etwas im Code geschrieben habe. Da konnte ich mitten in einer Prozedur einen Mini-Egoshooter programmieren und wusste Monate später, dass es mir da gerade langweilig war und die Zeilen nichts mit der eigentlichen Prozedur zu tun haben. Heute versuche ich, soweit es mir meine Programmierkenntnisse zulassen, minimalistisch zu sein. Nichts Unnötiges rein wofür man später Minuten braucht um den Sinn zu verstehen. Try Finally und Try Except haben einen Sinn. Ok, früher habe ich tatsächlich auf Try Except verzichtet, da ich mir Arbeit gemacht habe und zuerst alles überprüft habe ob evtl. ein Fehler vorkommen könnte. Ich mag nun mal keine Überraschungen. Wenn ich eine Datei laden wollte, dann prüfte ich zuerst ob die Datei da ist, wenn ich einen String-Zahl in Zahl konvertieren wollte, habe ich zuerst geprüft ob der String nur aus Zahlen besteht. Heute stehe ich auf dem Standpunkt, dass Fehlermeldungen Informationen sind mit denen man arbeiten kann.

Trotzdem, ich würde FreeAndNil nicht mit Try Except vergleichen. Na gut, ich hab noch nicht alles im Leben programmiert, aber ich hab auch noch nie im Leben eine Fehlermeldung, weil ich kein FreeAndNil genutzt habe. Noch nie. Try Except hat wenigstens einen Sinn, denn man kann mit dem Prüfen auch übertreiben. Natürlich kann man vor dem Schreiben einer Datei prüfen ob der Datenträger schreibgeschützt ist oder voll, man kann sich die Information aber auch aus der Fehlermeldung holen.

Aber wozu FreeAndNil? Weil kein Kurzzeitgedächtnis nicht funktioniert und ich innerhalb der gleichen Prozedur, nur drei Zeilen weiter mich nicht mehr erinnere, dass ich ein Objekt bereits freigegeben habe und nochmal damit arbeiten möchte? Und komm mir nicht einer mit Funktionen die ein Objekt oder ein freigegebenes Objekt zurückliefern. Da setzt man Nil als Information bewusst ein.

Nein, auf den Sinn und Unsinn von FreeAndNil lasse ich mich immer ein. Wie das mit den von dir erwähnten Interfaces aussieht, vielleicht. Da kenne ich mich weniger aus. Aber in einer normalen Prozedur FreeAndNil einzusetzen ist die kleine Herzchen über dem i zu zeichnen. Weil es schöner aussieht. Aber welchen Sinn hat es?

_________________
Popov

jaenicke · Verfasst: Mi 06.05.15 16:08

Popov hat folgendes geschrieben :

Aber wozu FreeAndNil? Weil kein Kurzzeitgedächtnis nicht funktioniert und ich innerhalb der gleichen Prozedur, nur drei Zeilen weiter mich nicht mehr erinnere, dass ich ein Objekt bereits freigegeben habe und nochmal damit arbeiten möchte?

Innerhalb der gleichen Prozedur ist ja nur eine kleine Möglichkeit. Es gibt aber auch noch globale Variablen (hoffentlich wenige) und sehr viel häufiger Variablen bzw. Felder einer Klasse und auch, und da ist es besonders von Bedeutung, Klassenvariablen. Bei denen ist der Scope deutlich größer...

Popov · Verfasst: Mi 06.05.15 16:39

Das würde ich sagar als Ausnahme akzeptieren. Aber dann nehme ich FreeAndNil nicht weil man es immer so macht, sondern weil ich mit dem Nil mitteilen will, dass das Objekt freigegeben worden ist. An einer anderen Stelle kann ich prüfen ob es Nil ist und entsprechend reagieren.

Dagegen Anfängern erzählen, dass man FreeAndNil nehmen muss, finde ich sehr bedenklich. Sie nehmen an, dass es notwendig ist, obwohl Free ausreicht. Ich meine, das machst du ja auch nicht, oder?

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

var
  a, b: Integer;
begin
  a := 2;
  b := 3;
  ShowMessage(IntToStr(a + b));
  a := 0;
  b := 0;
end;

Nur für den Fall der Fälle, dass du nach ShowMessage nochmal mit a oder b arbeiten könntest.

_________________
Popov

FaTaLGuiLLoTiNe · Verfasst: Mi 06.05.15 16:50

jaenicke hat folgendes geschrieben :

Ein anderer Aspekt ist, dass ein FreeAndNil dafür sorgt, dass bei einer späteren erneuten Freigabe oder Benutzung eine Zugriffsverletzung an Adresse 0 passiert.

Ist das so? Ich bin mir eigentlich ziemlich sicher, dass ein Free (oder FreeAndNil) auf einer Instanzvariablen, die den Wert Nil hat, zu keiner Fehlermeldung - geschweige denn Speicherfreigabe - führt. Und das würde ich eher noch als weiteren Vorteil von FreeAndNil ins Feld führen.

_________________
<< FaTaLGuiLLoTiNe >>
Rhinoceroses don't play games!

Ehemaliges Mitglied Erhaltene Danke: 1

Wozu noch eine Diskussion über FreeAndNil?

Sucht man allein nur in der Delphipraxis nach dem Thema FreeAndNil, findet man schon unzählige Diskussionen darüber, die alle ohne Einigung (was ja wohl auch nicht der Sinn einer Fachdiskussion darstellt) ausgehen bzw. aufhören. Google findet dazu nochmal ca. 60.000 Diskussionen und Meldungen. In allen diesen Diskussionen, Artikeln und was auch immer wird alles rund um FreeAndNil bis auf das letzte Byte ausgeleuchtet, abgewogen, geraten, abgeraten usw., so daß ich mich schwer damit tue, Sinn und Zweck einer weiteren Diskussion für und wider FreiAmNil auch nur ansatzweise erkennen zu können. Offenbar haben die Leute alle soviel Zeit neben der eigentlichen Arbeit, dieses Thema – angesichts der bereits unzählien Diskussionen – wieder und wieder durchzukauen und dabei mit schöner Regelmäßigeit hauptsächlich das eigene Ego zu streicheln und alle anderen Egos, die nicht zustimmen, deutlich abzuwerten – ein déjà vu, wie ich es hier und heute nicht zum ersten Mal erlebe :twisted:

More on FreeAndNil
Unterschied zwischen nil, FreeAndNil und Free in TForm
Using FreeAndNil
Verunsicherung mit Destructor, Free und FreeAndNil
Nur free oder FreeandNil
Klasse.Free oder FreeAndNil(Klasse) ??
FreeAndNil geht nicht
Problem mit TIcon und FreeAndNil
free oder freeAndNil()
Unterschied zwischen FreeAndNil(Objekt) und Objekt.Free
FreeAndNil() auf Array anwenden?
Warum FreeAndNil so umständlich?
Fehler bei FreeAndNil(TObjekt)
Probleme mit FreeandNil
Vor- und Nachteile von FreeAndNil und Free
Problem mit FreeAndNil
zugriffsverletzung bei Freeandnil
Free oder FreeAndNil=
TStringList mit Objekten: Free oder FreeAndNil?
Frage zu FreeAndNil
Free, FreeAndNil und mehrere Variablen
(Liste verständlicherweise unvollständig)

Wäre es nicht am besten, man programmiert die Forensoftware so, daß sie bei Fragen zu FreeAndNil automatisch auf all die bereits existierenden Threads verweist und die Annahme weiterer derartiger Threads unterbindet? :lol:

Ist natürlich ein Scherz, aber mit etwas ernstem Hintergrund ... :twisted:

Martok · Verfasst: Mi 06.05.15 17:06

FaTaLGuiLLoTiNe hat folgendes geschrieben :

Ist das so? Ich bin mir eigentlich ziemlich sicher, dass ein Free (oder FreeAndNil) auf einer Instanzvariablen, die den Wert Nil hat, zu keiner Fehlermeldung - geschweige denn Speicherfreigabe - führt. Und das würde ich eher noch als weiteren Vorteil von FreeAndNil ins Feld führen.

Japp, Free ist die einzige Methode (von TObject) die explizit auf Self<>Nil prüft. Deswegen verwendet man auch immer .Free statt .Destroy - diese Überprüfung bekommt man nur so. Und genau da hilft dann FreeAndNil gegen doppteltes Freigeben.

Die Sache ist eben, dass man für den Preis von wenigen CPU-Zyklen ganze Klassen von Bugs ausschließt bzw sehr einfach auffindbar macht. Ich finde schon, dass es das wert ist.

Perlsau hat folgendes geschrieben :

Wäre es nicht am besten, man programmiert die Forensoftware so, daß sie bei Fragen zu FreeAndNil automatisch auf all die bereits existierenden Threads verweist und die Annahme weiterer derartiger Threads unterbindet? :lol:

Ist natürlich ein Scherz, aber mit etwas ernstem Hintergrund ... :twisted:

Tut sie schon. Versuch mal ein Thema mit dem Titel zu erstellen :zwinker:

Das hilft natürlich nicht gegen Leute, die das unbedingt als Off-Topic in einem anderen Thema machen wollten.

_________________
"The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."

Popov · Verfasst: Mi 06.05.15 17:46

@Perlsau

Die einen führen Diskussionen, andere erstellen Listen aus der Suche. Jeder macht was er für richtig hält.

Aber um dir zu erklären wieso ich die Diskussion führe, zitiere ich mal den ersten Beitrag den ich in deiner Liste angeklickt habe.

Zitat:

In einer TStringList mit OwnsObjects: Werden mit FreeAndNil auch die Objekte der Listenelemente freigegeben, oder reicht dazu Free aus?

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

MyStringList := TStringList.Create;
MyStringList.OwnsObjects := True;
try
  while DerTagLangIst do
    MyStringList.AddObject(AString, TMyObj.Create);
finally
  //MyStringList.Free;
  FreeAndNil(MyStringList); // besser?
end;

Wieso stellt PeterPanino diese Frage? Ganz einfach, weil dieses inflationäre Nutzen von FreeAndNil die Leute nur verrückt macht. Es ist nicht nötig, aber es ist chic. Leute die das machen sind die iPod Nutzer unter den MP3-Player Nutzern. Man spaltet sich von der Masse ab.

Der Grund wieso PeterPanino fragt ob es besser ist FreeAndNil zu nutzen ist der, weil er nicht versteht wieso die es einige Leute überhaupt nutzen. Also fragt er und bekommt persönliche Meinungen. Es gibt nun mal Leute die speziell Programmieren. Und manchmal, aber nur nachts zwischen 22:30 und 03:15 Uhr und nur dann wenn Vollmond ist und gerade ein gelber VW-Käfer vorbeifährt, ist die Situation da wo FreeAndNil tatsächlich Sinn macht.

Also, wer FreeAndNil gerne nutzt und sich mit Schlangenöl gegen Hexenschuss vorbeugend einreibt, der soll es machen. Aber bitte den Leuten nicht erklären, dass es notwendig ist. Wäre es notwendig, gäbe es kein Free, sondern nur ein FreAndNil.

_________________
Popov

Ehemaliges Mitglied Erhaltene Danke: 1

Popov, ich finde, du schreibst Quark. All diese Fragen und persönlichen Meinungen wurden doch bereits bis zum Abwinken gepostet. Das hier ist lediglich eine Wiederholung vorangegangener Diskussionen über FreeAndNil, mit all den bereits bis zum Erbrechen durchgekauten Argumenten und Gegenargumente. Wer sich über das Thema informieren will, findet so viele gegensätzliche oder auch nur leicht voneinander abweichende Meinungen darüber, wie sie auch in diesem Thread wieder zu finden sind. Daher ist der Sinn & Zweck einer erneuten Diskussion über FreeAndNil fragwürdig bis nicht existent – sieht man einmal davon ab, daß man sich hier prima wichtig machen kann: "Ich bin schließlich an der Uni und lehre dort, also habt ihr mir zu glauben, wenn ich sage, daß ..." wie man von dir sinngemäß hin und wieder zu lesen bekommt.

Wie gesagt, die Diskussion hier bringt auch nichts Neues über FreeAndNil, was nicht schon tausendmal geschrieben wurde. Dafür dient die Diskussion dir und einigen wenigen anderen zur Egopflege und dem Niedermachen anderer:

Popov hat folgendes geschrieben :

Leute die das machen sind die iPod Nutzer unter den MP3-Player Nutzern. Man spaltet sich von der Masse ab.
Es gibt nun mal Leute die speziell Programmieren. Und manchmal, aber nur nachts zwischen 22:30 und 03:15 Uhr und nur dann wenn Vollmond ist und gerade ein gelber VW-Käfer vorbeifährt, ist die Situation da wo FreeAndNil tatsächlich Sinn macht.
Also, wer FreeAndNil gerne nutzt und sich mit Schlangenöl gegen Hexenschuss vorbeugend einreibt, der soll es machen.

Aber um dir zu erklären wieso ich die Diskussion führe, zitiere ich mal den ersten Beitrag den ich in deiner Liste angeklickt habe.

Du, Popov, ich habe nicht dich persönlich angeschrieben und um eine Erklärung deiner Beweggründe gebeten, die interessiert mich eigentlich weniger, weil sie, wie bereits angedeutet, vorgespiegelt ist. Du kannst offenbar nicht sachlich bleiben, du mußt immer andere in deinen Post in den Schmutz ziehen. Das ist deine Motivation, die kenne ich bereits zur Genüge. Und du fühlst dich stets von jedem, der nicht deine Ansichten und Meinungen teilt, angegriffen und nimmst das persönlich, du bist ja Dozent, wie du niemals müde wirst zu betonen, und deshalb muß der Narses der Nini die Sachen auch so beibringen, wie du es für richtig hältst, und wenn er's nicht tut, mischt du dich in seinen Thread ein und weist ihn darauf hin, daß du als Dozent weißt, was Lerneffekt bedeutet und er sich gefälligst danach zu richten habe, was ein Uni-Dozent vorschreibt. Also wirklich nicht!

Martok · Verfasst: Mi 06.05.15 18:18

Popov hat folgendes geschrieben :

Also, wer FreeAndNil gerne nutzt und sich mit Schlangenöl gegen Hexenschuss vorbeugend einreibt, der soll es machen. Aber bitte den Leuten nicht erklären, dass es notwendig ist. Wäre es notwendig, gäbe es kein Free, sondern nur ein FreAndNil.

Gestern hatten wir so schöne Fischereimetaphern, da nehm ich heute mal was aus der Industrie: FreeAndNil ist wie ein Arbeitsschutzschuh.
Wenn du in der Arbeitsvorbereitung bist und im Büro sitzt brauchst du ihn praktisch nie, aber wenn du mal an die Maschinen kommst und dir da was auf die Füße fällt, wirst du dir wünschen du hättest rechtzeitig dran gedacht. Zumal es die Dinger heute echt bequem gibt und man damit auch problemlos normal sitzen kann.

Mein MP3-Player ist übrigens ein Samsung-Dumbphone. Wobei das inzwischen auch ein Abspaltungsmerkmal ist :roll:

_________________
"The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."

Popov · Verfasst: Mi 06.05.15 20:46

Perlsau hat folgendes geschrieben :

Popov, ich finde, du schreibst Quark.

Deine Meinung.

Zitat:

All diese Fragen und persönlichen Meinungen wurden doch bereits bis zum Abwinken gepostet.

Perlsau, ich hab das Thema nicht angefangen. Ich bin noch nicht mal der Grund wieso es den Thread gibt. Ich hab mich einfach eingeklingt. Was machst du mir also nun Vorwürfe?

Zitat:

Das hier ist lediglich eine Wiederholung vorangegangener Diskussionen über FreeAndNil, mit all den bereits bis zum Erbrechen durchgekauten Argumenten und Gegenargumente.

Ich kann mich nicht erinnern je eine Diskussion darüber geführt zu haben. Soll es also bedeuten, dass man über Themen die schon mal geführt wurden, man nicht mehr diskutieren darf?

Zitat:

sieht man einmal davon ab, daß man sich hier prima wichtig machen kann: "Ich bin schließlich an der Uni und lehre dort, also habt ihr mir zu glauben, wenn ich sage, daß ..."

Ach so darum geht es. Den Dozenten kannst du geschenkt haben. Darauf bilde ich mir nicht ein, bis auf, dass Leute die vom Lerneffekt reden einfach keine Ahnung haben worüber die reden.

Zitat:

Wie gesagt, die Diskussion hier bringt auch nichts Neues über FreeAndNil

Doch. Nini hat heute was gelernt, denn sie hat nach Free ein Nil gesetzt. Nun wird sie glücklich einschlafen. Die nächsten zwei Jahre wird sie aber damit verbringen darüber nachzugrübeln wozu das Nil eigentlich gut war.

Zitat:

Dafür dient die Diskussion dir und einigen wenigen anderen zur Egopflege und dem Niedermachen anderer:

Ich hab kein sonderlich ausgeprägtes Ego. Wo habe ich irgendwen niedergemacht? Manchmal bin ich direkt. Nicht weil ich einen beleidigen will, sondern weil ich ein Minimalist bin. Ich mache kein Show drumherum, ich sage direkt was ich meine. Ist kein niedermachen, ist nur eine direkte Art.

Zitat:

Du, Popov, ich habe nicht dich persönlich angeschrieben und um eine Erklärung deiner Beweggründe gebeten

Nein, aber der Thread ist da. Welche Beweggründe hast du, dass die Diskussion nicht geführt wird?

Aber nun wirst du persönlich:
- "die interessiert mich eigentlich weniger, weil sie, ..., vorgespiegelt ist"
- "Du kannst offenbar nicht sachlich bleiben"
- "du mußt immer andere in deinen Post in den Schmutz ziehen."
- "Das ist deine Motivation, die kenne ich bereits zur Genüge."
- "Und du fühlst dich stets von jedem, ..., angegriffen und nimmst das persönlich"
- "du bist ja Dozent"

Wer ist hier persönlich?

_________________
Popov

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme