Verfügbarkeit von Objecten in unterschiedlichen Units

[berens]

Zitat von fisipjm:

Der initialization Teil ist in meinen Augen Sinnlos, korrigiert mich bitte wenn ich Falsch liege
Hier wird kein Create durchgeführt sondern ein Nil Pointer auf ein Objekt gesetzt, dass es eigentlich noch nicht geben dürfte. Es sei den, du erzeugst das Objekt direkt beim Programmstart (Quelltext des Projekts selbst und nicht in der Unit). Selbst dann müsste es aber "leer" sein.

Moin,
tja, ich leide an Fehler-Paranoia

Tatsache ist, das es für mich sehr "diffus" ist, wann/ob Delphi Variablen richtig initialisiert. Der Arbeitsspeicher (RAM) deines Computers wird ja wiederverwendet: Wenn du ein Programm zumachst, wir der Arbeitsspeicher frei, in dem Sinne von "Keine Referenz zeigt mehr darauf", aber der RAM wird -meines Wissens(!) nicht "Formatiert", so dass nach Programmende der komplette Arbeitsspeicher auf 0000000 steht, sondern es bleibt zunächst mal alles so wie es gerade ist. Wenn du nun in Delphi neue Variablen und Objekte hast, die einen Zeiger auf den Arbeitsspeicher bekommen mit "den darfst du benutzen, da arbeitet aktuell niemand mit", bedeutet das nicht, dass nun der komplette Arbeitsspeicher auf 0 gesetzt wird, sondern dass dort immernoch ein Buchstabensalat stehen *könnte*, und somit in einer brandneuen, uninitialisierten integer Variable der Wert 17 steht, in einem String "adfkgjzudfdui", und in bei einem Zeiger auf ein Objekt dieses bei Assigned(MeinObjekt)=True zurück geben könnte.

Wie gesagt, das ist nur die Paranoia. In der Delphi Hilfe finde ich bei den einzelnen Datentypen (Integer, TComponent, String, ...) NICHT, *ob* die Variablen immer initilaisiert werden (string='' integer=0 TMeinObjekt=NIL) und wenn ja, mit welchem Wert.

Damit ich nicht böse überrascht werde, oder in einer neuen Delphi Version auf einmal alles gehandhabt wird (Hey, deine widestring-variable ist nun beim Programmstart nicht mehr '' sonder NIL!) initialisiere ich lieber 100x unnötig alles per Hand, kann dann aber sicher sein, dass alles wirklich so ist, wie erwartet.

Also: Ja, beim Programmstart wird die MeinObjekt (unnötig) auf NIL gesetzt - damit stelle ich sicher, dass assigned() in der entsprechenden Methode auch wirklich 100% sicher sagen kann, ob das Objekt *gültig* existiert, oder nicht. Wie gesagt, assigned(MeinObjekt) könnte(?) evtl. true bei sein, obwohl ich noch kein Objekt erzeugt habe. Die Funktion erzeugt dann das gültige Objekt und gibt es zurück.

Ja, wahrscheinlich alles komplett übertrieben und unnötig, aber ich habe mit Delphi einfach schon viel zu viel Bulls*** erlebt, als dass mich sowas noch wundern würde.

Zeigt mir gerne wo steht, dass *ALLE* Variablen und Objekte stets mit 100% Zuverlässigkeit mit NIL, 0 oder "" initialisiert werden.
--> Danke für den Link, ich hatte bei "Integer" und "Einfache Typen" gesucht, aber bei "Variablen" war zu einfach . Tatsächlich trifft das aber dennoch nur auf globale, nicht auf lokale Variablen zu.

ChatGPT sagt dazu:

Zitat:

In Delphi werden globale Variablen und Felder von Objekten (also Klasseninstanzvariablen) automatisch mit nil initialisiert. Lokale Variablen, wie in deinem Beispiel die Variable b in der Prozedur, werden dagegen nicht automatisch auf nil gesetzt, wenn du sie nicht explizit initialisierst. Das bedeutet:

Globale Variablen und Klassenfelder: Immer nil, wenn sie noch keinen gültigen Wert erhalten haben.
Lokale Variablen (in Prozeduren/Funktionen): Können uninitialisiert sein und daher zufällige (Garbage‑)Werte enthalten, die nicht nil sind.

Die offizielle Embarcadero-Dokumentation zum Verhalten der Funktion Assigned und der Speicherinitialisierung bestätigt, dass nur Variablen, die explizit initialisiert wurden (oder als globale/Membervariablen deklariert sind), sicher den Wert nil besitzen. Wird eine lokale Variable nicht initialisiert, kann ein zufälliger Speicherwert vorliegen, wodurch Assigned(b) unter Umständen true zurückgeben kann.

Leider hat das der Link gefehlt.

Okay, also globale Variablen und Objekte scheinen das Problem nicht zuhaben, lokale schon. Was soll das denn bitte?
Gut, mein initialisieren ist unnötig, aber ich kotze im Strahl mit den 1000 Sonderfällen und Ausnahmeregelungen in Delphi wann was geht oder nicht geht, oder wann was automatisch passier und wann nicht. So ist es mehr Tipp-Arbeit und unnötig, aber zumindest ist damit meine Speicherverwaltung konsistent für lokale und globale Variablen.

Ich hätte Schreiner werden sollen...

[Uwe Raabe]

Man kann globale Variablen auch gleich bei der Deklaration initialisieren:

Delphi-Quellcode:

var
  FMeinObjekt: TMeinObjekt = nil;

[jaenicke]

Zitat von berens:

Zeigt mir gerne wo steht, dass *ALLE* Variablen und Objekte stets mit 100% Zuverlässigkeit mit NIL, 0 oder "" initialisiert werden.

Das ist eindeutig dokumentiert:
https://docwiki.embarcadero.com/RADS...ables_(Delphi)

Zitat:

If you do not explicitly initialize a global variable, the compiler initializes it to 0. Object instance data (fields) are also initialized to 0. On the Wiin32 platform, the contents of a local variable are undefined until a value is assigned to them.

When you declare a variable, you are allocating memory which is freed automatically when the variable is no longer used. In particular, local variables exist only until the program exits from the function or procedure in which they are declared.

Anders sieht es bei referenzgezählten Datentypen aus (strings, Interfaces, ...). Die werden auch lokal mit 0 initialisiert, was einfach daran liegt, dass ansonsten bei der ersten Zuweisung versucht würde, den alten Speicher freizugeben (obwohl der Wert gar nicht gültig wäre).

[fisipjm]

Zitat von berens:

Tatsache ist, das es für mich sehr "diffus" ist,

Hier gibt's eine gute Übersicht wie was wo im Standard initialisiert wird.
https://stackoverflow.com/questions/...lue-by-default

Auch immer gut in der Entwicklung wenn du schon beim Thema Speichermanagement bist, ReportMemoryLeaksOnShutdown := true in den Programmstart packen. Falls du das noch nicht kanntest bzw. hast
https://docwiki.embarcadero.com/Libr...eaksOnShutdown