Zitat von
Tyrael Y.:
FreeAndNil hat seinen Sinn, mach bitte einen neuen Thread dazu auf und ich bin bereit das zu beantworten ...
Nein, vielen Dank, über die Bienen und Blümchen bin ich schon aufgeklärt und über FreeAndNil braucht mich auch keiner aufklären
Zitat von
DataCool:
Aber Fakt ist:
Wenn man "Multi-Threaded" arbeitet ist es schon ne feine Sache mit FreeAndNil zu Arbeiten,
und vor dem Zugriff auf die Variable mit Assigned(xyz) zu prüfen,
ob es noch existiert.
Wie ich schon gesagt habe, das sind spezielle Situationen wo man bewußt mit der Information Nil arbeitet. Das ist etwas anderes. Nur wie gesagt - das sind bewusste Situationen wo Nil eine Information darstellt. Allerdings scheint es eine Mode zu sein, denn man sieht das allgemein. Es wird sogar Newbies empfohlen lieber FreeAndNil anstelle von Free zu nehmen. Wozu? Das ist Sinnlos.
Und nein, mir ist noch kein einziges Mal mein Programm um die Ohren geflogen weil ich auf ein Objekt zugegriffen habe das nicht da ist. Und ja, auch ich arbeite gelegentlich mit der Information Nil, aber dann wird Nil bewußt gesetzt. FreeAndNil ist als ob man mit Variant Variablen arbeiten würde. Dann kann man die Variable als String nutzen und kann sogar damit rechnen wenn zufällig nur Zahlen drin vorkommen. Eigentlich kann man dann sofort zu VB wechseln.
EDIT:
Zitat von
Christian Seehase:
Nimmt man einen const Parameter kommt man damit nicht durch, da einem der Compiler auf die Finger haut.
Freigeben kann ich das damit übergebene Objekt ja immer. Egal ob es nun ein var- out- const- oder WertParameter ist.
Du schlägst aber einen sehr weiten Bogen. Ich arbeite eigentlich zu 100% nach der Methode 3. Ich weiß, daß ich im Leben noch nicht alles programmiert hatte, aber Probleme deswegen hatte ich noch nie. Sicher, auch ich bin ein Absicherungsfanatiker und die hälfte meines Codes besteht manchmal nur aus Absicherungen und Abfragen. Ich hasse System-Errors, die kommen bei mir eigentlich nie vor. Und wenn, dann sind es meine eigene Fehlermeldungen. Aber man kann es auch übertreiben.