Spring4D Nullable<T> fHasValue: string;

[Dennis07]

Zitat von freimatz:

Es ist aber kein "object" sondern ein record

Naja, das kommt darauf an, wie man object hier interpretiert.
Wenn damit Objekttypen, also TChild = object(TAncestor) gemeint sind, dann hast du recht. Allerdings sind ja zunächst einmal record bzw. class -Instanzen auch Objekte ( -> "Instanzen eines vordefinierten Typs").

[Stevie]

Zitat von himitsu:

Weil der String automatisch initialisiert wird und ein Boolean ohne vorherrige Zuweisung sonst einen Zufallswert haben kann.

Korrekt

Zitat von freimatz:

Bei einem Nullable<Boolean> braucht man dann statt einem Byte dann 9.

Ein Nullable<Boolean> ist auf 32bit 8 Byte groß (wegen dem Alignment). Habe schonmal packed in Betracht gezogen, aber der Speicherverbrauch von Nullables ist mir bisher nicht als triftiges Problem berichtet worden.

Zitat von dummzeuch:

Man könnte das nach einer Idee von Allen Bauer mit einem Interface auf 4 Bytes reduzieren. Keine Ahnung, warum Stefan das nicht gemacht hat.

Eine string Referenz hat dieselbe Größe wie die eines interfaces (SizeOf(Pointer)) und es ist einfacher, einen Stringwert als "nicht null" Wert zuzuweisen, als mit der handcrafted IMT - zudem kann man das schöner im Debugger anschauen. Hat auch Hallvard Vassbotn in den Kommentaren vorgeschlagen.

Sollt es nachweislich einen Memoryleak durch diese Implementierung geben, dann bitte einen Bugreport mit komplettem Code zum nachstellen erstellen.

[freimatz]

Zitat von Dennis07:

Werden Felder nicht automatisch initialisiert?
Mir war doch so, und die OH sagt sazu:
Object instance data (fields) are also initialized to 0.
...

Zitat von Dennis07:

Zitat von freimatz:

Es ist aber kein "object" sondern ein record

Naja, das kommt darauf an, wie man object hier interpretiert.
Wenn damit Objekttypen, also TChild = object(TAncestor) gemeint sind, dann hast du recht. Allerdings sind ja zunächst einmal record bzw. class -Instanzen auch Objekte ( -> "Instanzen eines vordefinierten Typs").

Nein es kommt nicht drauf an wie "man" es definiert sondern wie es EMB definiert. Und das ist IMHO eindeutig.

@Stevie: bis jetzt habe ich noch nicht die Implementierung in Verdacht.

[Dennis07]

Ja ne, dürfte ja klar sein, dass ich das so gemeint habe.
In wie fern ist das jetzt bitte "eindeutig", ob es sich um object oder einfach Objekte handelt? Geht hier aus dem Kontext keineswegs hervor. Klar kann man sagen "isso", aber das ist ja dann nicht eindeutig.
Was beispielsweise ist dann mit Klassen? Verhalten die sich wie Records oder wie Objects? (Antwort weiß ich zwar, bleibt aber ungeklärt, wenn man den Satz so deutet).
Also ganz klar ein Problem der schwammigen Formulierung des Satzes.

[freimatz]

Du verwirrst mich. Jetzt versteh ich es selber nicht mehr. Vorher dachte ich wenigstens ich hättes verstanden.
Die Seite mit "Object instance data (fields) are also initialized to 0" habe ich nochmals genauer gelesen. Da geht es doch nur um "initialize a global variable". Darum ging es mir mit den Nullable<T> nicht. Die werden in dem Projekt alle als member von Klassen, also Nachfahren von TObject, verwendet.

[himitsu]

Globale Variablen, und Felder in Objekten, werden mit 0 initiliaisiert. (bei Globalen kann man auch optional einen anderen Wert vorgeben)
Lokale Variablen in Funktionen werden nicht initialisiert (mit Ausnahme ein paar weniger Typen, wie z.B. der String)

Beim Result von Funktionen mal so und mal so (je nach Typ), aber eigentlich auch nie so, wie man es braucht, also sind praktisch nie sicher "richtig" initialisiert (auch nicht für String und Co.).