Records

[Sinspin]

Eine Record-Variable/Feld die in einer Klasse enthalten ist, sollte mit Null initialisiert sein, so wie alle anderen Felder der Klasse auch. Aber in Methoden/Proceduren/Funktionen sind lokale Variablen egal welchen Typs nie initialisiert.

[himitsu]

Die Lösung nennt sich Custom Managed Records.
https://docwiki.embarcadero.com/RADS...anaged_Records

Delphi-Quellcode:

type
  TMyRecord = record
    Value: Integer;
    class operator Initialize(out Dest: TMyRecord);
  end;

class operator TMyRecord.Initialize(out Dest: TMyRecord);
begin
  Dest.Value := 10;
end;

[jaenicke]

Ja, in diesem Fall ist das sicher die einfachste Lösung, da man dafür nur die Records selbst anfassen muss, nicht aber deren Verwendung im Quelltext.

[TSchnuckenbock]

Ich hab' eben mal im Code geschaut, wie ich generell programmiere....meine Vermutung war, daß ich generell alle Variablen initialisiere. Und genauso ist es. Ich verlasse mich nirgends darauf, wie eine eventuell Vorbelegung aussehen könnte. (Ich habe wenigstens auf die Schnelle keinen Code gefunden, in dem es anders ist.)
Bei Klassen geschieht das im Kontruktor oder es gibt z.B. eine Methode "Init" oder sowas in der Art. Da werden dann alle Felder einer Klasse mit Default-Werten vorbelegt, Events kriegen z.B. nil zugewiesen.

Im alten Code, den ich übernommen habe, könnte es aber anders aussehen.

[himitsu]

Managed Typen sind immer initialisiert (außer jemand pfuscht mit Pointern rum und verwendet die falsche Methode, zum Reservieren des Speichers)

Globale Variablen und Thread-Variablen werden durch Windows immer initialisiert (standardmäßig mit 0),
außer es wurde für eine globale Variable ein Initialisierungs-Wert angegeben.
Genauer gesagt, liegen globale Varaiblen in eine Sektion (Speicherbereich) der EXE/DLL.

Objekt-Felder (die Variablen in Delphi-Objekten) sind ebenfalls immer mit 0 initialisiert.
siehe das FillChar in TObject.InitInstance

Lokale Variablen (also auf dem Stack) sind normal nicht initialisiert.
* Ausnahme sind Managed Typen
Result ist nicht initialisiert
* Ausnahme sind Managed Typen (nur sind sie nicht dort initialisiert, wo ihr es denkt :twisted:)
* neuerdings werden z.B. Boolean-Results mit False initialisiert, weil ständig zuviele Leute grob fahrlässig die Compiler-Warnungen nicht lesen.

[TSchnuckenbock]

Ach ja, die Compiler-Meldungen bzgl. eventuell nicht initialisierten Sachen, schaue ich mir an und behebe das.
Das hat unsere Software übigens merklich stabiler gemacht.

[Edelfix]

Währe es so nicht noch besser?

Delphi-Quellcode:

class operator TMyRecord.Initialize(out Dest: TMyRecord);
begin
  //Dest.Value := 10;
  Dest := Default(TMyRecord);
end;

Scheint aber nicht zu funktionieren.

[Phoenix]

Zitat:

Zitat von Uwe Raabe (Beitrag 1528956)

Zitat:

Zitat von Der schöne Günther (Beitrag 1528944)

Kann man einem da wirklich einen großen Vorwurf draus machen wenn der Compiler noch nicht einmal vor so etwas warnen kann?

Meiner Meinung nach, ja. Es ist natürlich einfach, die Schuld an einem Programmfehler dem Compiler zu geben, der nicht clever genug ist, diesen zu entdecken. Vielleicht bin ich aber auch einfach nur zu altmodisch.

Bist Du. Sorry ;)

In C# z.B. sind alle Felder aller Typen (Structs, Records, Classes) immer automatisch mit ihren jeweiligen Default-Werten initialisiert.

Rust als unmanaged Sprache hat z.B. das Ownership-Konzept, mit dem das Memory Management komplett durch den Compiler abgesichert wird. Es ist dort schlicht nicht möglich, Code zu schreiben der Unfug mit fremden Speicher anstellt, Buffer overruns produziert oder zu Memory Leaks führt, da einem der Compiler hier extrem hart auf die Finger klopft.

Und das ist gut so.
Klar sollte man als Entwickler immer eine Ahnung haben von dem was man tut und grob von dem was auf der Hardware physikalisch passiert (also wo steht z.B. was im Speicher), aber das bedeutet nicht, dass das Tooling einen nicht so gut dabei unterstützen sollte wie es rechnerisch möglich ist.

Wenn der Compiler einem Stundenlanges(!) suchen(!) nach Problemstellen nicht abnimmt, obwohl es möglich wäre (z.B. ein Schalter, der Initialisierungs-Code für jeden Record generiert), dann ist das meiner Meinung nach ein massiver Grund, sich nach besserem Tooling umzusehen.

[Der schöne Günther]

Ich finde es zwar schon legitim, dass Delphi die Record-Felder nicht implizit initialisiert, ist ja eine Performance-Sache.

Aber überhaupt nichts zu sagen, wenn wirklich eindeutig ist, dass hier mit nicht initialisiertem Speicher gearbeitet wird, und einem keine Möglichkeit geben, solche Stellen nachträglich zu finden, das ist echt nicht mehr feierlich.

PS: Oh, von Rust brauchen wir echt nicht anfangen. Das ist wirklich eine ganz andere Liga, was der Compiler und Linter da einem teilweise erzählen. Mein Favorit bislang war noch "Hey, benenn doch deine Methode besser so und so um, weil dann wird klarer, dass du mit den Daten das und das tust".

[Phoenix]

Zitat:

Zitat von Der schöne Günther (Beitrag 1529108)

Ich finde es zwar schon legitim, dass Delphi die Record-Felder nicht implizit initialisiert, ist ja eine Performance-Sache.

Korrekt. Das aber zusätzlich anzubieten, als Option irgendwo alà "Ich weiß, es ist langsamer, aber ist auch sicherer, also mach an" wäre trotzdem nice.

Oder eben allein schon der Check als Compiler Hint oder gar Warning: "Hey, hier arbeitest Du mit nicht initialisierten Werten!", die Du dann beachten kannst oder aber im Stil von "Ich bin ein Software-Ingenieur, ich weiß, was ich tue", an der Stelle bewusst deaktivieren kannst, das wäre auch nett. Und ehrlich gesagt ist sowas inzwischen ja auch State-of-the-art.

So gern ich Pascal als Sprache immer noch lese - das sind so Dinge die mich einfach ganz krass davon abhalten, mir das wieder anzutun.
Aktuell bin ich mit TypeScript, C# und Python unterwegs, und je mehr linting und Compiler Support dort kommt, desto genialer finde ich das. Und desto effizienter werde ich mit der Zeit auch, weil ich, wenn ich einen Fehler mache, direkt vom Werkzeug darauf hingewiesen werde. Dann kann ich gucken was (und warum) ich das falsch gemacht habe, und lernen, wie ich das für die Zukunft vermeiden kann. Heißt im Umkehrschluss auch, ich produziere weniger Fehler und damit weniger Bugs, und spare mir damit schon von Afang an die Zeit, die ich sonst investieren müsste um die wieder zu fixen. :thumb: