10.4 : Warum Inline-Variablen?

[Harry Stahl]

Zitat von Harry Stahl:

Ich habe zufälligerweise gerade etwas dazu in diesem Beitrag geschrieben:

Zitat von jaenicke:

https://www.delphipraxis.net/1465551-post57.html

Type inference ist der Teil daran, der mir weniger gefällt, so praktisch es auch sein mag. Aber der Punkt, dass man genau den Typ angibt, den man meint, der Compiler es prüft usw. war immer eine der wichtigsten Stärken von Pascal / Delphi. Das wird damit aufgeweicht.

Erfreulicherweise läßt Delphi Dir die Wahl.

Statt
var files := System.ioutils.TDirectory.GetFiles (edDir.Text, '*.*');
kanst Du auch

var files : TStringDynArray := System.ioutils.TDirectory.GetFiles (edDir.Text, '*.*');
schreiben...

[Harry Stahl]

Zitat von jaenicke:

Inline Variablen sind so ähnlich wie with:
Erleichtert das Schreiben von Code, verringert die Lesbarkeit und Wartbarkeit aber deutlich.

Immerhin hat es weniger negative Auswirkungen als with. Wenn aber der Rückgabewert einer Methode sich ändert, ändert sich ohne Typangabe auch plötzlich der Typ. Und dann kommt an ganz anderer Stelle ein Fehler.

Ich finde außerdem, dass es den Quelltext schlechter lesbar macht.

Aber wie so vieles (Quelltextformatierung, ...) ist es eben Geschmackssache. Ich persönlich werde das Feature sicher sehr spärlich verwenden... außer bei Schleifen, wo es durchaus praktisch ist, dass die Variable danach nicht mehr verfügbar ist. Das muss jeder für sich selbst entscheiden.

Warum findest Du, dass es den Code schlechter lesbar macht? Ich habe da eher die gegenteilige Erfahrung gemacht.

Wenn ich mir eine Funktion ansehe, die ein anderer geschrieben hat (oder ich selber vor längerer Zeit) und sich da im Var-Bereich 5-10 Variablen-Deklarationen tummeln, weiß ich dann noch, wenn ich mir 50 Zeilen code durchgelesen habe, welchen Typ eine Variable hat, wenn sie zum ersten mal zum Einsatz kommt?

Per inline var kommt der Typ der Variable ins Spiel, wenn ich an der Stelle bin, wo die Variable gebraucht wird. Wenn die Variablenbezeichnung (z.B. sInitName) schon selbst den Typ erklärt, reicht ein


var sInitName := 'MusterMann';
Hab ich was komplexeres oder mehrdeutiges, dann nehme ich da noch den Typ hinzu:

Delphi-Quellcode:

var MyStdPowerSrc : TBattery := GetPower (PowerSrc);

// statt: MyStdPowerSrc :=  GetPower (PowerSrc);

Ich weiß dann genau an der Stelle wo die Variable zum Einsatz kommt, dass MyStdPowerSrc eben von der Klasse TBattery ist und muss nicht 40 Zeilen weiter oben nachsehen, ob MyStdPowerSrc nun TBattery oder TSolarPanel war, das noch an anderer Stelle in der Funktion in einem else-Zweig zum Einsatz kommt...

Aber so richtig hast Du ja noch gar nicht erklärt, warum Du der Meinung bist, dass die Lesbarkeit schlechter ist ...

[himitsu]

Zitat:

weiß ich dann noch, wenn ich mir 50 Zeilen code durchgelesen habe, welchen Typ eine Variable hat

Es gibt ja viele Leute, die uns versuchen beizugringen, dass Funktionen immer ganz Kurz sein müssen, und schon gibt es das Problem nicht.

Alternativ arbeitest du besser mit einem 21:9 Monitor im Hochformat und bekommst dann auch wieder die Funktion in einem Blick auf den Bildschirm.
oder besser gleich 16:3 https://www.itboost.de//eshop.php?ac...r_aid=10949605

[MyRealName]

Zitat von p80286:

Zitat von Uwe Raabe:

Zitat von Papaschlumpf73:

Ich kann auch gut ohne...

Konnten doch bisher alle, oder?

Das ist doch die Argumentation der ewiggestrigen, die sich jeder Neuerung sperren und die Flexibilität mit Chaos verwechseln. So bremst man den Fortschritt aus.

Gruß
K-H

Ich hatte es schonmal erwähnt, glaube ich, möchte aber hier im Thread nochmal ausdrücklich drauf hinweisen :

Als 10.3 rauskam habe ich ein Refactoring eines alten Services gemacht, der mit der Zeit aus dem Ruder lief. Das wollte ich dann auch gleich zusammen mit TMS Aurelius und einer neuen Modul-Factory, die ich mir überlegt hatte, machen. Da wollte ich natürlich auch gleich Inline Variablen ausprobieren. Erste Versuche sahen gut aus.
Aber als dann alles so halbwegs zusammengebaut war, gab es seltsame Effekte, Schutzverletzungen, die da nicht sein sollten. Ich habe Tage gesucht. Irgendwann habe ich in einem der Module, wo ich ständig Fehler hatte, dann doch alle Inline Variablen rausgeworfen. Siehe da, es funcktionierte, wie es sollte. Nachdem ich alle Inlines im ganzen Projekt rausgeworfen habe, traten keine Fehler mehr auf.

Vielleicht ist es ja besser seitdem, aber ich nutze dieses Feature mit Vorsicht.

[MyRealName]

Zitat von himitsu:

Zitat:

weiß ich dann noch, wenn ich mir 50 Zeilen code durchgelesen habe, welchen Typ eine Variable hat

Es gibt ja viele Leute, die uns versuchen beizugringen, dass Funktionen immer ganz Kurz sein müssen, und schon gibt es das Problem nicht.

Alternativ arbeitest du besser mit einem 21:9 Monitor im Hochformat und bekommst dann auch wieder die Funktion in einem Blick auf den Bildschirm.
oder besser gleich 16:3 https://www.itboost.de//eshop.php?ac...r_aid=10949605

Ich nutze einen 32:9 bei 5120 x 1440, aber der geht nicht hochkant, weil er curved ist. Ist aber trotzdem ein sehr gutes Arbeiten drauf und noch besseres Spielen.

[Rollo62]

Wo ich das gerade sehe, wer hat mit Inline schon was getestet ?

Kann die Inline-Variable in einem Scope auch umdeklariert werden, vielleicht so ?
Ich würde erwarten das es geht, aber die Erfahrung lehrt mich ...

Delphi-Quellcode:

var MyStdPowerSrc := TBattery.Create;
MyStdPowerSrc.Free

...

var MyStdPowerSrc := TSolarPanel.Create;  //wird hier der Typ TBattery gg. TSolarPanel getauscht ?
MyStdPowerSrc.Free

Ich vermute mal das es nicht geht, weil dann verschachtelte Prozeduren damit nicht klarkommen.

[Der schöne Günther]

Ein schönes praktisches Beispiel wie man sich selbst ins Knie schießen kann hat Microsoft kürzlich erzählt. Ein uralter Bug in FAT32 lag im Endeffekt auch an einer unglücklich platzierten Deklaration einer Variable:

(Runterscrollen zu "Use-After-Free in FAT32")
https://msrc-blog.microsoft.com/2020...ry-on-windows/

Zitat:

The code was something along the lines of this:

Code:

for(int i = 0; i < size; i++)
{
      int tmp;
      DoStuff(&tmp, i);
}

This code was running in a loop. A variable was declared inside of the loop. On the first iteration of the loop, the function DoStuff would initialize the variable “tmp” that it is passed the address to. On every additional iteration of the loop, the variable “tmp” was used as an in/out parameter. In other words, the variable would be read from and then updated.

The issue here is that the variable comes in scope at the beginning of each iteration of the loop and goes out of scope after each iteration of the loop. With InitAll enabled, this variable is zero initialized for each iteration of the loop. This is effectively a use-after-free. This code is depending on the value of “tmp” being preserved each iteration of the loop even though it goes out of scope at the end of each iteration.

[Stevie]

Type Inference: Friend or Foe

[freimatz]

Zitat von MyRealName:

Als 10.3 rauskam habe ich ein Refactoring eines alten Services gemacht, der mit der Zeit aus dem Ruder lief. Das wollte ich dann auch gleich zusammen mit TMS Aurelius und einer neuen Modul-Factory, die ich mir überlegt hatte, machen. Da wollte ich natürlich auch gleich Inline Variablen ausprobieren. Erste Versuche sahen gut aus.
Aber als dann alles so halbwegs zusammengebaut war, gab es seltsame Effekte, Schutzverletzungen, die da nicht sein sollten. Ich habe Tage gesucht. Irgendwann habe ich in einem der Module, wo ich ständig Fehler hatte, dann doch alle Inline Variablen rausgeworfen. Siehe da, es funcktionierte, wie es sollte. Nachdem ich alle Inlines im ganzen Projekt rausgeworfen habe, traten keine Fehler mehr auf.

Selber schuld: Bei Software benutzt man NIE die erste Version (eines neuen Features) - erst recht nicht bei Delphi.

[Harry Stahl]

Zitat von Der schöne Günther:

Ein schönes praktisches Beispiel wie man sich selbst ins Knie schießen kann hat Microsoft kürzlich erzählt. Ein uralter Bug in FAT32 lag im Endeffekt auch an einer unglücklich platzierten Deklaration einer Variable:

(Runterscrollen zu "Use-After-Free in FAT32")
https://msrc-blog.microsoft.com/2020...ry-on-windows/

Zitat:

The code was something along the lines of this:

Code:

for(int i = 0; i < size; i++)
{
      int tmp;
      DoStuff(&tmp, i);
}

This code was running in a loop. A variable was declared inside of the loop. On the first iteration of the loop, the function DoStuff would initialize the variable “tmp” that it is passed the address to. On every additional iteration of the loop, the variable “tmp” was used as an in/out parameter. In other words, the variable would be read from and then updated.

The issue here is that the variable comes in scope at the beginning of each iteration of the loop and goes out of scope after each iteration of the loop. With InitAll enabled, this variable is zero initialized for each iteration of the loop. This is effectively a use-after-free. This code is depending on the value of “tmp” being preserved each iteration of the loop even though it goes out of scope at the end of each iteration.

Das ist aber Fehler, der auch auch ohne Inline-Var recht ähnlich möglich wäre:

Delphi-Quellcode:

var
  tmp: Integer;
begin
  for L := 1 to 10 do begin
    // tmp := 0;  <-- Oder so was
    inc (tmp);
    DoStuff (L, tmp);
  end;

Delphi würde Dir in dem oben beschriebenen C-Beispiel mit INLINE-Var eine Warnung ausgeben, dass tmp möglicherweise nicht initialisiert sei (so was wie ein "InitAll" gibts unter Delphi nicht).

Im meinem Fehler-Beispiel erhältst Du auch eine Warnung wegen der fehlenden Initialisierung (es sei denn Du initialisierst in der Schleife, dann nicht).

Aber ich sag mal: Jeder so wie er meint. Ich freue mich jedenfalls die zusätzliche Option zu haben und werde Sie auch nutzen, die Artikel in den Links, die ich oben genannt habe, führen ja auch sehr gute Gründe für eine Verwendung auf.

Wer es nicht mag, lässt es einfach...