Hi,

Ich wollte mal fragen, wie das mit der Variablen initaliesierung in Delphi üblich ist bei Klassen. Macht man das bei jeder Variable im Konsturktor?
Und man muss die Variablen zwingend auf Null setzten oder? Sonst gibt es ziemliche Probleme oder?

ich machs immer im constructor

Das kommt immer darauf an.
Wenn beim Zeitpunkt, bei dem die Instanz der Klasse erstellt wird, für bestimmte Variablen Werte angegeben sein sollen, macht man das im Konstruktor.
Für andere Variablen, die erst zur Laufzeit initialisiert werden kann man das auch bei der Deklaration machen.

Hier mal eine kurze Übersicht zu Variablen in Delphi: www.delphi-treff.de/...cal/variablen-konst/

Grundsätzlich gilt folgendes:
Wenn du eine Variable bis zur Verwendung nicht initialisiert hast, dann weißt du nicht was drin ist. Das kann z.B. 0 sein, muss aber nicht. Am sinnvollsten ist deshalb schon der Konstruktor zur Initialisierung, denn dann kann es keinen Punkt geben, an dem eine Variable nicht initialisiert ist.

Wenn du es dort aus irgendeinem Grund unterlässt, dann musst du das entsprechend dokumentieren und jede Verwendung muss das berücksichtigen. Wenn du dort zum Beispiel einer Objektvariable nil zuweist, weil du die erst später erzeugen willst, dann kannst du später mit Assigned testen, ob die Initialisierung stattgefunden hat oder nicht. Ohne Initialisierung kann dort auch 0xNIRWANA () drinstehen und du denkst die Klasse wurde schon erzeugt (<> nil) und es gibt bei der Benutzung einen Fehler.

Delphi initialisiert zwar manches selbst, aber besser ist es sich nicht darauf zu verlassen, sondern immer jede Variable im Konstruktor bzw. bei lokalen Routinen vor der Benutzung zu initialisieren. Das erspart manche unerklärlichen Fehler. Denn es können ja immer unterschiedliche Werte am Anfang drinstehen, so dass die Fehler variieren.

Hi,

Distemix hat folgendes geschrieben :

Ich wollte mal fragen, wie das mit der Variablen initaliesierung in Delphi üblich ist bei Klassen. Macht man das bei jeder Variable im Konsturktor? Und man muss die Variablen zwingend auf Null setzten oder? Sonst gibt es ziemliche Probleme oder?

Delphi initialisiert alle Felder einer Klasse automatisch mit 0, also integer und Fliesskomma als 0, Pointer, Objekte und Interfaces mit NIL, Strings als Leerstring.

Das ist dokumentiertes Verhalten des Compilers, man darf sich also darauf verlassen und muss die Initialisierung nicht selbst vornehmen, wenn 0 als Wert in Ordnung ist. (Einige hier im Forum werden widersprechen, Informatiklehrer evtl. auch.)

Dasselbe gilt fuer globale Variablen, *nicht* jedoch fuer lokale.

twm

Das ist schon richtig, aber erstens gibt es auch andere Compiler (und weitere werden vermutlich folgen), das heißt bei einer Migration hat man ggf. unerklärliche Fehler, wenn man nicht weiß, wenn das dort anders ist, zudem ist es in anderen Sprachen auch nicht immer so.

Deshalb bin ich eher für den gemeinsamen Nenner und initialisiere alles, sonst lasse ich es am Ende bei der falschen Sprache weg. Wer nicht in vielen Sprachen programmiert, sondern wirklich nur Delphi benutzt, für den mag das nicht entscheidend sein, aber in der Branche kann man ja kaum auf nur eine Sprache setzen. Eine fehlende Diversifikation kann sich später rächen.

Für den Hobbyprogrammierer ist das sicherlich nicht entscheidend.

@dummzeuch: Es gibt bei Delphi intern einen Unterschied, ob ein String leer ('') oder nicht zugewiesen (nil) ist. Es gibt nämlich einige wenige Funktionen der RTL die mit nil nicht zurechtkommen

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben :

@dummzeuch: Es gibt bei Delphi intern einen Unterschied, ob ein String leer ('') oder nicht zugewiesen (nil) ist. Es gibt nämlich einige wenige Funktionen der RTL die mit nil nicht zurechtkommen ;-)

Hm, ich wusste, dass es diesen Unterschied theoretisch geben kann:

string = nil

bzw.

string = pointer auf einen String-Deskriptor mit Length=0

(Und dann gibt es natuerlich noch ShortString, aber den will ich mal aussen vor lassen.)

Aber welche RTL-Funktionen kommen denn nicht mit NIL zurecht? Und warum ist das nicht gefixt worden? Oder sind das jetzt Funktionen, deren Parameter nicht ein String sondern ein PChar ist?

twm

dummzeuch hat folgendes geschrieben :

Und warum ist das nicht gefixt worden?

Weil es nicht auffällt, wenn man alles initialisiert.

jaenicke hat folgendes geschrieben :

dummzeuch hat folgendes geschrieben : Und warum ist das nicht gefixt worden? Weil es nicht auffällt, wenn man alles initialisiert. :P

Wenn ich BenBE richtig verstanden habe, so kommen einige RTL-Funktionen nicht damit klar, wenn ein String ein NIL-Pointer ist. Das wiederum ist eine korrekte Initialisierung fuer einen String, denn der Compiler macht genau das aus:



Wenn Du mir das nicht glaubst, schau Dir einfach den erzeugten Assemblercode an.

Ich kann ja verstehen, dass Du auf Deiner Meinung beharrst, man solle immer alles initalisieren und sich nicht darauf verlassen, dass der Compiler das schon richtig macht. Und wegen mir darfst Du mich auch gerne fuer einen Amateur halten, der nach 15 Jahren in dem Job immernoch keine Ahnung hat, wie man professionell Software entwickelt, aber bitte halte mir das nicht jedesmal vor, wenn es gar nichts zur Sache tut.

twm

nein, er meinte doch, falls er mal den code portieren möchte! wer weiß, ob der neue compiler immer noch diese initialisierung vornimmt. daher sei es das sicherste, wenn man es selbst macht

Wie gesagt: ich initialisiere vor allem deshalb alles, weil ich keinerlei Lust habe mir für jede Sprache und jeden Compiler zu merken was der wann initialisiert.
Insgesamt benutze ich mind. 9 Sprachen / Scriptsprachen mit 11 Compilern, vielleicht auch mehr, die sind mir jetzt auf Anhieb eingefallen. Die Syntax und Befehle lernt man automatisch und merkt man sich automatisch, solche Sachen müsste ich aber einfach stupide auswendig lernen, und da mir das wenig bringt, lasse ich es.
Und bei einer Portierung müsste ich dann neben der Behebung von Fehlermeldungen auch noch den ganzen Code daraufhin überprüfen.

Ich habe nie etwas dagegen gesagt, dass man es weglässt, wenn man bei einem bestimmten Compiler weiß, dass der es automatisch macht und keinen anderen benutzt. Ich habe nur gesagt, dass ich es eben nicht bei jedem weiß und mich deshalb nicht darauf verlassen kann. Delphi ist der einzige Compiler, bei dem ich dazu überhaupt etwas im Kopf hatte was da wohl passiert (was jetzt in dem Thread auch als richtig bestätigt ist). Bei allen anderen habe ich nicht die leiseste Ahnung ob die das machen und es ist mir auch nicht wichtig das zu wissen.

Ich wuesste immernoch gerne, welche RTL-Funktionen nicht mit Nil-Pointer Strings klarkommen.

Siehe fastcode.sourceforge.net/ unter Rules. Dort ist ne entsprechende Erwähnung, auf die ich meine Aussage stütze. Welche das konkret sind, müsste man im VCL-Source nachgucken.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben :

Siehe fastcode.sourceforge.net/ unter Rules. Dort ist ne entsprechende Erwähnung, auf die ich meine Aussage stütze. Welche das konkret sind, müsste man im VCL-Source nachgucken.

Meinst Du das hier:
"The rule above implies that functions must support non-nil-zero-length strings only if the RTL function does."

Das bedeutet wohl, dass die RTL teilweise mit Leerstrings nicht klarkommt, die nicht NIL sind, also das Gegenteil von dem, was Du oben gesagt hattest:

Zitat:

@dummzeuch: Es gibt bei Delphi intern einen Unterschied, ob ein String leer ('') oder nicht zugewiesen (nil) ist. Es gibt nämlich einige wenige Funktionen der RTL die mit nil nicht zurechtkommen ;-)

Na, jetzt bin ich aber beruhigt.

twm