Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Die Delphi-IDE (https://www.delphipraxis.net/62-die-delphi-ide/)
-   -   Wozu ist die CompilerVersion vom Typ Extended ? (https://www.delphipraxis.net/205092-wozu-ist-die-compilerversion-vom-typ-extended.html)

Rollo62 30. Jul 2020 18:07

Wozu ist die CompilerVersion vom Typ Extended ?
 
Hallo zusammen,

ich habe gerade in der Dokumentation nachgesehen,
Zitat:

CompilerVersion CompilerVersion: Extended = 34;
weil ich mich über die Angaben mal 34, mal 34.0 wundere.

Wer um Alles in der Welt hat für die CompilerVersion den Typ Extended ausgesucht,
gibt es dafür irgendeinen rationalen Grund ?

Gut, Extended ist meiner Meinung nach das komplette Gegenteil eines präzisen numerischen Wertes,
deshalb wäre Integer * 100 oder sowas MEINE Wahl gewesen ( so wie es auch bei VER340 gezählt wird).

Bei ungünstigen Abfragen auf = 34.0 könnte man sich üble Rundungs-Fehler einhandeln
( OK, ich mache sowieso bei Vergleichen immer >= 34.0, dann ist es schon machbar ).

Auf der anderen Seite könnte Embarcadero denken das Delphi ewig bestehen wird,
und dass dann mit Extended die Version näher am Unendlichen ist :stupid:

Was hat sich der Meister dabei nur gedacht :gruebel: ?

hoika 30. Jul 2020 18:15

AW: Wozu ist die CompilerVersion vom Typ Extended ?
 
Hallo,
http://docwiki.embarcadero.com/RADSt...iler-Versionen

D2007 ist 18.5

"Beachten Sie bitte, dass für Delphi 2007 zwei VERxxx-Symbole (VER180 und VER185) definiert sind. Delphi 2006 und 2007 sind binär kompatibel, sodass 180 mit beiden arbeitet. Verwenden Sie VER185, wenn Sie nur 2007 benötigen"

Rollo62 30. Jul 2020 18:37

AW: Wozu ist die CompilerVersion vom Typ Extended ?
 
Ja ist schon klar.
Nur ist Extended für Vergleiche eben extrem schlecht, weil floating point.
Ausserdem hätte Single dann wohl auch gereicht.

Was solls, ich muss das ja nicht verstehen :stupid:

Uwe Raabe 30. Jul 2020 18:40

AW: Wozu ist die CompilerVersion vom Typ Extended ?
 
Da sowohl CompilerVersion als auch die 34.0 Konstanten vom gleichen Typ sind, sollte ein Vergleich auf Gleichheit schon passen.

Rollo62 30. Jul 2020 18:51

AW: Wozu ist die CompilerVersion vom Typ Extended ?
 
Zitat:

Zitat von Uwe Raabe (Beitrag 1470858)
Da sowohl CompilerVersion als auch die 34.0 Konstanten vom gleichen Typ sind, sollte ein Vergleich auf Gleichheit schon passen.

Ist ja wohl ein ähnliches Thema, vor einer Minute
https://www.delphipraxis.net/205093-...ml#post1470857

Nur leider kann man SameValue in der bedingten Compilierung nicht nutzen weil nicht intrinsisch, soweit ich weiss.


Das 34.0 = 34.0 gleich ist will ich mal hoffen,
wobei natürlich Abfragen auf exakt = 34.0 auch extrem selten vorkommen dürften.
Es könnte mal angenommen sein, dass nur eine bestimmte Version ein bestimmtes Problem hat,
dann würde man aber besser statt "= 34.0" doch eher ">=" und "<=" nehmen.

Also ich würde zum Beispiel statt "= 34.0" <===> das nehmen "( >=34.0 ) and ( < 34.1 )",
um ganz sicher zu sein.

Andreas13 30. Jul 2020 20:45

AW: Wozu ist die CompilerVersion vom Typ Extended ?
 
Hallo Rollo62,
in diesem Fall ist ein unscharfer Vergleich nicht notwendig, weil die typisierte Konstante
Delphi-Quellcode:
 
CONST
  CompilerVersion: Extended = 34;
per Deklaration und nicht als das Ergebnis einer Berechnung zustande kommt. Damit gibt es keine Rundungsfehler. Wenn Du Deine Compiler-Version ähnlich deklarierst
Delphi-Quellcode:
 
CONST
  MyCompilerVersion: Extended = 34;
Dann hast Du dieselbe Bitcodierung, also eine wirklich identische Extended-Zahl. Bei Single oder Double wäre das nicht der Fall. Daher ist die eindeutige Typangabe
Delphi-Quellcode:
 Extended
erforderlich, damit ein Vergleich auf exakte Gleichheit hinhaut.
Gruß, Andreas

Rollo62 31. Jul 2020 06:25

AW: Wozu ist die CompilerVersion vom Typ Extended ?
 
Na schön, ich gehe halt immer gerne auf Nummer sicher.

Du meinst also bei
Delphi-Quellcode:
 
CONST
  CompilerVersion: Single = 34;
 
CONST
  MyCompilerVersion: Single = 34;

Result :=  CompilerVersion = MyCompilerVersion; // Ok, weil gleiche Typen, gleiche Bitkodierung
wäre ein direkter Vergleich möglich ?
Ist ja auch die identische Bitkodierung.

Nur wenn ich direkte konstante Zahlen, und keine mit Typ deklarierten Konstanten, im Vergleich eingebe
dann könnte das den Unterschied ausmachen.

Delphi-Quellcode:
 
CONST
  CompilerVersion: Single = 34;

Result :=  CompilerVersion = 34.0; // Möglicherweise OK, wenn intrinsische Typumwandlung 34.0 auf Extended
Result :=  CompilerVersion = 34;   // Problematisch weil womöglicherweise verschiedene Typen (Integer)
Es gibt ein paar interessante Links dazu:
http://www.delphibasics.co.uk/Article.asp?Name=Numbers
http://rvelthuis.de/articles/articles-floats.html

aber irgendwie finde ich gerade nicht welchen Typ ( ABC = 34.0) eine nicht-deklarierte Konstante eigentlich bekommt.
- nimmt die den Typ an, den ABC hat ? (davon gehe ich eigentlich aus (= der Compiler optimiert so dass keine Conversion nötig ist)
- wird die immer zu Extended (conversion könnte passieren) ?
- wird die immer zu Double (conversion könnte passieren) ?

Bei Embarcadero habe ich auf die Schnelle nichts dazu gefunden ( gibt es aber bestimmt). :stupid:

Andreas13 31. Jul 2020 07:25

AW: Wozu ist die CompilerVersion vom Typ Extended ?
 
Nicht jede Dezimal-Zahl ist binär exakt codierbar. Bereits hier könnte es ohne eindeutige Typangaben zu internen Rundungsfehlern kommen. Beispiel:
Delphi-Quellcode:
CONST
  CompilerVersion_e: Extended = 34.1;
  CompilerVersion_s: Single  = 34.1;
  CompilerVersion_d: Double  = 34.1;

  CompilerVersion_o = 34.1; // o: Ohne Typangabe

Begin
    WriteLn('Extended = Single:  Ist Gleich? = ', CompilerVersion_e = CompilerVersion_s);
    WriteLn;
    WriteLn('Extended = Double:  Ist Gleich? = ', CompilerVersion_e = CompilerVersion_d);
    WriteLn;
    WriteLn('Extended = Extended: Ist Gleich? = ', CompilerVersion_e = CompilerVersion_e);
    WriteLn;
    WriteLn('Extended = OHNE Typ: Ist Gleich? = ', CompilerVersion_e = CompilerVersion_o);
    WriteLn;

    WriteLn('SizeOf(CompilerVersion_e) = ', SizeOf(CompilerVersion_e));
    WriteLn('SizeOf(CompilerVersion_s) = ', SizeOf(CompilerVersion_s));
    WriteLn('SizeOf(CompilerVersion_d) = ', SizeOf(CompilerVersion_d));
    WriteLn('SizeOf(CompilerVersion_o) = ', SizeOf(CompilerVersion_o));
   
    ReadLn;
End;
Inndiesem Fall (34.1) ist:
(Extended = Single) ---> False
(Extended = Single) ---> False
(Extended = Double) ---> True
(Extended = Extended) ---> True
(Extended = Ohne Typ) ---> True // Der Compiler verwendet hier automatisch Double

Warum? Weil die Dezimalzahl 34.1 binär nicht exakt darstellbar ist und je nach Real-Type intern „ein bißchen“ anders aussieht.

Ändern wir die Konstanten jeweils auf 34, so sieht es ganz anders aus: Alle Vergleiche liefern True, aber für die nicht-typisierte Konstante hat der Compiler (XE5) den Datentype Byte gewählt.
Fazit: Um das Ergebnis des Vergleichs nicht dem Zufall & der Compilerversion zu überlassen, sollten wir die Konstante durch Typisierung eindeutig festlegen.
Gruß, Andreas

himitsu 31. Jul 2020 08:47

AW: Wozu ist die CompilerVersion vom Typ Extended ?
 
Currency wäre hier bestimmt vollkommen ausreichend und "optimaler" gewesen.

Aber für ganze und halbe Versionen sollte es meisten kein Probleme bereiten.

Uwe Raabe 31. Jul 2020 10:18

AW: Wozu ist die CompilerVersion vom Typ Extended ?
 
Zitat:

Zitat von Andreas13 (Beitrag 1470882)
Nicht jede Dezimal-Zahl ist binär exakt codierbar.

Korrekt! Allerdings haben wir hier einen besonderen Fall: Die Compiler-Version bleibt in absehbarer Zeit vermutlich zweistellig und die Nachkommastelle ist wohl allenfalls eine 5 (=½) und sonst 0. Damit lässt sich diese Zahl auch immer exakt als Extended (vermutlich sogar Double oder Single) darstellen. Um alle ganzen und halben Versionen bis 127.5 darzustellen braucht es gerade mal die ersten 7 Bit in der Mantisse und die letzten 3 vom Exponent.


Alle Zeitangaben in WEZ +1. Es ist jetzt 11:24 Uhr.
Seite 1 von 2  1 2      

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