Delphi-Version: 10.2 Tokyo
IfThen Implementation
Hallo,
ich frage mal nach weil ich nix dazu in der Hilfe finden kann, ist das Verhalten von IfThen auch in höheren kaputt? Ich meine damit wenn die Argumente 2 oder 3 eine Dereferenzierung eines Objekts verwenden und Argument 1 prüft ob das möglich ist. Delphi führt dann auch den Zweig aus, der nicht wahr ist was zu einer Zugriffsverletzung führt. |
AW: IfThen Implementation
IfThen ist eine Function. Da werden die Parameter vor dem Aufruf ausgewertet und dann an die Function übergeben. Folglich müssen alle Parameter für IfThen auch fehlerfrei ausgewertet können.
Das hat auch nichts mit der Implementierung zu tun, sondern mit der Art und Weise wie Functions in Delphi/Pascal aufgerufen werden. |
AW: IfThen Implementation
Das ist einer der Gründe weshalb ich die Verwendung von IfThen in den meisten Fällen nicht empfehle:
Es ist ein unnötiger zusätzlicher Aufruf an eine Funktion mit einem unnötigen Aufruf für einen der Parameter und stopft mehrere Befehle unnötigerweise in eine Zeile, was der Übersicht abträglich ist. Deshalb ist es meistens sinnvoller wirklich ganz normal mit if..then zu arbeiten. Ausnahme ist so etwas:
Delphi-Quellcode:
Da kann es übersichtlicher sein, wenn man die Berechnung nicht dupliziert und auch das Ergebnis des IfThen nicht vorher zwischenspeichert.
Left := 250 * DPIFactor + IfThen(Screen.Width > 1080, 200, 100);
// feste Werte in beiden Fällen und Teil eines komplexeren Ausdrucks Ich persönlich nutze es aber auch da nicht. |
AW: IfThen Implementation
Eigentlich ist IfThen() nur sinnvoll einzusetzen, wenn die beiden möglichen Rückgabewerte Konstanten oder konstante Ausdrücke sind.
|
AW: IfThen Implementation
In C-Spachen ist IfThen bzw ?: ein Makro, was die Parameter, bzw. die übergebenen Codes, erst auswertet, wenn "wirklich" drauf zugegriffen wird, also bei TRUE nur das vom True-Parameter.
In Delphi ist es (leider) eine stinknormale Funkltion, bei der auch das Inline nicht dabei hilft den "unnötogen" Parameter nicht vorher aufzulösen, also alles was als Parameter rein geht, wird vorhr ausgeführt/aufgelöst und nur die Ergebnisse (die Werte an die Parameter) werden anschließend entsprechend zurückgegeben (oder nicht). Selbst von der Pascal/Delphi-Syntax her, ohne Inkompatibilitität zur bestehenden Syntax, wäre es möglich "einfache" Makros auch ins Delphi zu bekommen, aber der Hersteller weigert sich vehement, was sehr schade ist. |
AW: IfThen Implementation
Die Dereferenzierung wird zur Laufzeit gemacht, daher ist die Auswertung aller Zweige zur Laufzeit nicht notwendig.
Der ternäre Operator in C-artigen Sprachen macht das meines Wissens auch nicht. Üblicherweise verwendet ich das in Logs als Logger.Log(Format('barcode:%s', IfThen(Assigned(entry), entry^.bc, ''))) aber das erzeugt Zugriffsverletzungen weil der Compiler das nicht prüft aber kaputten Code zur Laufzeit erzeugt. Also mehr als nur unschön weil man sowas eher zufällig mitbekommt. |
AW: IfThen Implementation
Bei beiden wird der Code im Compiler erzeugt (zur Laufzeit ändert sich nichts mehr),
aber bei dem C-Makro wird der "Code" innerhalb des Makros ausgewertet (hier kann dann der ungenutzte Teil/Parameter übersprungen werden), und in Delphi eben schon alle Parameter vor Aufruf der Funktion. Auch in C würde es knallen, wenn IfThen dort als Funktion implementiert wäre. Einzig was (aktuell) ginge, wären z.B. den Parameter-Code Funktionen/Methoden/AnonymeMethoden auszulagern und diese im IfThen auszuwählen, weil zwar die Methoden-Zeiger vorher aufgelöst werden, aber der Methoden-Inhalt erst dann ausgeführt würde, wenn ausgewählt. |
AW: IfThen Implementation
Delphi-Quellcode:
Hat diese Implementation dieses Problem auch?
function IfThen(pCondition: Boolean; const pBranchTrue, pBranchFalse: String): String;
begin if pCondition then Result:= pBranchTrue else Result:= pBranchFalse; end; |
AW: IfThen Implementation
ja,
aber so lange man nur ein Varialen oder Konstanten übergibt und nichts bei Übergabe zusammensetzt/aufruft, stört es nicht. Das IfThen aus der StrUtils sieht praktisch genauso aus, außer daß es noch als INLINE deklariert ist, was aber nur beeinflußt ob die Funktion direkt aufgerufen wird, oder der IFCode an Stelle des Aufrufers steht. Wenn makromäßig bei Inline die Parameter an den Stellen im code eingefügt und das dann kompiliert würde, dann würde es gehen, aber hier wird erst aufgelöst und dann nur das Result also der Parameter (die Temp-Variable) an den Stellen genutzt. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:53 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz