Übergebenes nil erkennen?

[MaBuSE]

Zitat von solus:

Im eigentlichen Anwendungsfall lag keine lokale Variable sondern ein Feld eines Objekts vor.
Gilt hier dasselbe und sollten die Variablen demnach vom Konstruktor wenn benötigt auf nil gestzt werden?

Grundsätzlich sollte ein Programmierer nie dem Compiler vertrauen und alle Variablen initialisieren.

Der Compiler gibt auch Warnungen beim Compilieren aus.
-> http://www.delphi-treff.de/tutorials...wirds-wichtig/

Versuche grundsätzlich Deine Anwendung so zu schreiben, dass keine Warnungen und Hinweise auftreten.

Ausnahme: Warnungen die Du selbst einbaust {$message warn 'Hier muss ich noch mal genau prüfen !!!'} oder {$message hint 'TODO: Quellcode muss noch kommentiert werden, damit es auch ein anderer versteht ;)'} .
Wenn Du Deinen Code immer sauber hällst, fallen solche eigenen Hinweise und Warnungen natürlich auf und animieren Dich das angemahnte auch zu tun.

Zitat von solus:

Analoge Frage: Werden globale Variablen initialisert?

Ja, wenn man sie z.B. so definiert:

Delphi-Quellcode:

...
var
  s: string = 'DefaultWert';
  i: Integer = 0;
...

[Stevie]

Zitat von MaBuSE:

Grundsätzlich sollte ein Programmierer nie dem Compiler vertrauen und alle Variablen initialisieren.

Ich frag mich gerade, ob du selber deinen Bytecode schreibst, wenn du das nicht tust. Dass Felder initialisiert werden, ist dokumentiertes Verhalten. Ordinalwerte sind 0, Boolean ist False, Zeiger sind nil, Strings sind leer.

[himitsu]

Nja, war'n bissl langsamer beim Lesen.

[MaBuSE]

Zitat von Stevie:

Zitat von MaBuSE:

Grundsätzlich sollte ein Programmierer nie dem Compiler vertrauen und alle Variablen initialisieren.

Ich frag mich gerade, ob du selber deinen Bytecode schreibst, wenn du das nicht tust. Dass Felder initialisiert werden, ist dokumentiertes Verhalten. Ordinalwerte sind 0, Boolean ist False, Zeiger sind nil, Strings sind leer.

Wenn es dokumentiert ist, ist das was anderes.
Meines Wissens ist es nur für Strings doumentiert.

[edit]Undokumentiere Dinge, die man "nur" durch ausprobieren weiss, können sich ja jederzeit bei einem Versionswechsel ändern.[/edit]

Wo steht das denn in der Doku?

[MaBuSE]

Zitat von MaBuSE:

Wo steht das denn in der Doku?

Ich habs gerade gefunden:

In der Delphi Hilfe steht ( http://docwiki.embarcadero.com/RADStudio/XE2/de/Variablen )

Lokale Variablen können nicht in ihren Deklarationen initialisiert werden. Aufeinander folgende Variablendeklarationen (z. B. var X, Y, Z: Real;) dürfen weder Initialisierungen enthalten noch Deklarationen von Varianten und Dateitypen.

Wenn Sie eine globale Variable nicht explizit initialisieren, wird sie vom Compiler mit 0 initialisiert. Objektinstanzdaten (Felder) werden auch mit 0 initialisiert. Auf der Wiin32-Plattform ist der Inhalt von lokalen Variablen so lange undefiniert, bis ein Wert zugewiesen wird.

Der bei der Deklaration einer Variablen zugewiesene Speicher wird automatisch freigegeben, wenn die Variable nicht mehr benötigt wird. Lokale Variablen werden freigegeben, wenn die Prozedur oder Funktion beendet wird, in der sie deklariert sind. Weitere Informationen über Variablen und die Verwaltung des Speichers finden Sie unter Speicherverwaltung.

Wobei 0 <> nil um die Frage vom Threadersteller zu beantworten.

[sx2008]

Zitat von MaBuSE:

Wo steht das denn in der Doku?

Etwas versteckt, hier:
http://docwiki.embarcadero.com/Libra...t.InitInstance
Setzt alle Speicherzellen in dem für ein neues Objekt reservierten Bereich auf Null und initialisiert den Zeiger auf die Tabelle der virtuellen Methoden der Instanz.

[himitsu]

Zitat von MaBuSE:

Wenn es dokumentiert ist, ist das was anderes.
Meines Wissens ist es nur für Strings doumentiert.

[edit]Undokumentiere Dinge, die man "nur" durch ausprobieren weiss, können sich ja jederzeit bei einem Versionswechsel ändern.[/edit]

Wo steht das denn in der Doku?

Windows initialisiert Speicher mit 0, wenn man den bei ihm reserviert, somit sind die globalen Variablen auch initialisiert.
Und beim Erstellen von Objekten wird definitiv ein FillChar mit 0 über den Instanzspeicher gejagt.

Zitat von MSDN: VirtualAlloc:

Reserves or commits a region of pages in the virtual address space of the calling process. Memory allocated by this function is automatically initialized to zero, unless MEM_RESET is specified.

Zitat von OH: TObject.InitInstance:

Setzt alle Speicherzellen in dem für ein neues Objekt reservierten Bereich auf Null und initialisiert den Zeiger auf die Tabelle der virtuellen Methoden der Instanz.

Und ansonsten werden auch Strings (ausgenommen der ShortString), dynamische Arrays, Interfaces und Variants immer initialisiert.
Das gilt aber nur die Variablen selber und nicht den Inhalt der Arrays oder Strings ... diese sind wie lokale Variablen, also uninitialisiert, bis auf die genannten Sonderfälle.

[Bummi]

@Mabuse

Delphi-Quellcode:

var
 T:Tbutton;
begin
  t := nil;
  Showmessage(IntToHex(Integer(t),8));
end;

[Medium]

0 <> nil (bzw. NULL) gilt nur semantisch, und ist meist in Datenbanken auch so umgesetzt, wie auch in einigen wenigen Sprachen. In Delphi (und auch C) wird für die Darstellung von nil/NULL der numerische Wert 0 genommen, da er wenn dereferenziert in ungültigen Speicher zeigt, und somit niemals für eine gültige Referenz stehen kann (zumindest in Sprachen, in denen Referenz = Zeiger auf Speicher ist). Theoretisch ist also tatsächlich 0 <> nil, aus praktischen Gründen gilt in Delphi aber doch 0 = nil.

[himitsu]

Wobei Delphi auch hart typsicher unterscheidet.

Du kannst einen Pointer nicht auf 0 setzen oder einen Integer auf nil.
Für den Variant gibt es den Wert NULL (auch als Konstante) und wenn man dem Variant eine 0 zuweist, dann ist was was Anders.

Daß intern, also die Daten im RAM, der Integer (eigentlich aber richtiger Cardinal) NativeUInt den selben Wert aufweisen, das ist soweit richtig.
Dennnoch

Delphi-Quellcode:

nil <> 0
Cardinal(nil)   = 0  // nur für 32 Bit, da ein paar Idioten meinten Integer/Cardinal einfrieren zu müssen
NativeUInt(nil) = 0