Inkompatible Datentypen in Procedures bei Arrays mit Double bzw. Extended

[Stevie]

Zitat von enigma:

Delphi-Quellcode:

  varDouble := 1.2;
  varExt := 7.3;
  arrDouble: array[0..2] of Double = (1.1, 2.2, 3.3);
  arrExt: array[0..2] of Double = (1.0, 2.0, 3.0); // <--- !!!

Falscher Typ, oder?

Und nein, auch wenn Typ X auf Typ Y zuweisungskompatibel ist, ist ein Array von X nicht auf ein Array von Y zuweisungkompatibel.

[himitsu]

Extended soll man eh nicht verwenden, somit ist es egal.
Estended war eh niemals für die direkte Verwendung/Speicherung vorgesehn.

Und beim Überladen hast mit Extended außerhalb Windows (Android/iOS/OSX) wowieso Probleme, da es diesen Typ dort nicht gibt.
OK ihn gibt es, aber er ist dort intern ein Double und schon hast mit deiner Überladung ein kleines Problemchen.

Zitat:

Delphi-Quellcode:

type
  TExtArr = array of Extended;
  TDblArr = array of Double;

procedure AcceptMe(AArr: TExtArr); overload;
procedure AcceptMe(AArr: TDblArr); overload;

Hier hast ein Problem, dass es nur genau diesen Typen annimmt und nichts Anderes.

Es ist allgemein besser, hier einen Standardtypen zu nutzen, denn so kann man dieses Array nicht nur mit der eigenen, sondern auch mit fremden Funktionen nutzen.

Delphi-Quellcode:

type TDblArr = TArray<Double>;  // oder TDoubleDynArray
procedure AcceptMe(AArr: TDblArr); overload;

oder als offenes Array deklarieren,
procedure AcceptMe(AArr: array of Double); overload;
denn sowas nimmt viele Arrays an, die aus irgendeinem Array von Double bestehen,
also direkt ein Konstanten-Array ala [1.1, 2.2, 3.3] übergeben oder andere Array-Typen aus Doubles
und sogar statische Arrays ala array[0..15] of Double (siehe Post #1).

[Uwe Raabe]

Zitat von himitsu:

OK ihn gibt es, aber er ist dort intern ein Double

Na ja, so ganz stimmt das aber auch nicht: https://docwiki.embarcadero.com/RADS...hi)#Real_Types

[himitsu]

Intern ist der Typ "Extended" entweder 10 Byte (Extended) oder 8 Byte (Double), je nach OS und Bitigkeit.

Wie groß der Typ nach außen ist, das hängt davon ab, wie, je nach OS, der Speicher aligned wird und wie der Compiler eingestellt wurde.
Da kann er 8 bis 16 Byte sein, oder auch garnicht existieren.
{$EXTENDEDCOMPATIBILITY ON}

Hmm, OK, das mit Linux hatte ich nicht mitbekommen,
aber da es Apple praktisch nur noch als 64 Bit gibt und man den 32 Bit-iOS-Simulator (Intel) vergessen kann,
bleiben ja nur noch Win32 und Linux übrig (auf x86 ... nicht auf ARM, falls es das jemals gibt).

Ich frag mich nur, wie Linux das eigentlich machen will? (der Typ OK, aber damit auch "schnell" rechnen .. nicht wie der emulierte Int64/UInt64 im Win32)
Das war doch ein Ding der FPU und Jene gibt es in der 64 Bit-CPU (Intel/AMD) nicht mehr, sowie nicht im ARM.


Offiziell Ursprünglich (außerhalb der Pascal/Delphi-Welt) war Extended eh nie zum Speichern vorgesehn, sondern vorwiegend nur für Zwischenschritte von Berechnungen.
Aber OK, falls C-Compiler den Typ nicht kennen, dann kann man ihn auch dort teilweise aktivieren.
"long double" (80-bit double extended format) im C++, bzw. double-double damals auf PowerPC.




Nja, wird eh Zeit, dass wir Float128 (quadruple precision) im Delphi bekommen, was uns im IEEE 754 versprochen wurde.

[Andreas13]

Zitat von himitsu:

Nja, wird eh Zeit, dass wir Float128 (quadruple precision) im Delphi bekommen, was uns im IEEE 754 versprochen wurde.

quadruple precision gibt's derzeit nur als externe Delphi-Bibliothek von Erik van Bilsenhttps://github.com/neslib/Neslib.MultiPrecision. Allerdings kennt die zugrundeliegende C++-Bibliothek noch kein +/- Unendlich und liefert bei manchen algebraischen Operationen anstelle von 0 (z.B. bei 1/Unendlich) noch sinnlose Fehlermeldungen. Habe bereits vor etlichen Monaten den Urheber der C++-Bibliothek auf https://www.davidhbailey.com/dhbsoftware/ um Korrektur gebeten, was auch versprochen wurde. Anscheinend ist aber das Problem komplexer als es scheint.
Gruß, Andreas

[enigma]

Vielen Dank für eure hilfreichen Tipps!
Auf overload bin ich inzwischen selbst gekommen