AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

10.4 : Warum Inline-Variablen?

Ein Thema von himitsu · begonnen am 27. Mai 2020 · letzter Beitrag vom 1. Jun 2020
Antwort Antwort
Seite 2 von 5     12 34     Letzte » 
Benutzerbild von Harry Stahl
Harry Stahl

Registriert seit: 2. Apr 2004
Ort: Bonn
2.164 Beiträge
 
Delphi 10.4 Sydney
 
#11

AW: 10.4 : Warum Inline-Variablen?

  Alt 27. Mai 2020, 22:25
Ich habe zufälligerweise gerade etwas dazu in diesem Beitrag geschrieben:

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...
  Mit Zitat antworten Zitat
Benutzerbild von Harry Stahl
Harry Stahl

Registriert seit: 2. Apr 2004
Ort: Bonn
2.164 Beiträge
 
Delphi 10.4 Sydney
 
#12

AW: 10.4 : Warum Inline-Variablen?

  Alt 28. Mai 2020, 00:20
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 ...
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
38.400 Beiträge
 
Delphi 10.4 Sydney
 
#13

AW: 10.4 : Warum Inline-Variablen?

  Alt 28. Mai 2020, 00:55
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
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Heilbronn
516 Beiträge
 
Delphi 10.4 Sydney
 
#14

AW: 10.4 : Warum Inline-Variablen?

  Alt 28. Mai 2020, 08:55
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.
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Heilbronn
516 Beiträge
 
Delphi 10.4 Sydney
 
#15

AW: 10.4 : Warum Inline-Variablen?

  Alt 28. Mai 2020, 08:59
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.
  Mit Zitat antworten Zitat
Rollo62

Registriert seit: 15. Mär 2007
3.150 Beiträge
 
Delphi 10.4 Sydney
 
#16

AW: 10.4 : Warum Inline-Variablen?

  Alt 28. Mai 2020, 09:00
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.
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
5.658 Beiträge
 
Delphi 10 Seattle Enterprise
 
#17

AW: 10.4 : Warum Inline-Variablen?

  Alt 28. Mai 2020, 09:18
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.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.823 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#18

AW: 10.4 : Warum Inline-Variablen?

  Alt 28. Mai 2020, 10:50
Type Inference: Friend or Foe
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
freimatz

Registriert seit: 20. Mai 2010
984 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#19

AW: 10.4 : Warum Inline-Variablen?

  Alt 28. Mai 2020, 13:43
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.
  Mit Zitat antworten Zitat
Benutzerbild von Harry Stahl
Harry Stahl

Registriert seit: 2. Apr 2004
Ort: Bonn
2.164 Beiträge
 
Delphi 10.4 Sydney
 
#20

AW: 10.4 : Warum Inline-Variablen?

  Alt 28. Mai 2020, 16:03
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...

Geändert von Harry Stahl (28. Mai 2020 um 16:19 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +2. Es ist jetzt 20:50 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf