Kann Rudy's Big Number library nicht kompilieren…

[Andreas13]

Halllo Community,
am 7. Apr 2023 konnten wir im Beitrag https://www.delphipraxis.net/212826-...pi-delphi.html erfahren, daß Rudy's Big Number library https://github.com/TurboPack/RudysBigNumbers erfreulicherweise weitergepflegt wird. :-D

Hat jemand von Euch versucht, damit zu arbeiten?
Ich kann den Source-Code mit XE5 leider nicht kompilieren: Die Unit Velthuis.XorShifts.pas liefert mehrere Fehlermeldungen wie z. B.
[dcc32 Fehler] Velthuis.XorShifts.pas(160): E2029 Anweisung erwartet, aber 'VAR' gefunden

Weiß jemand einen Rat?
Danke im Voraus!

[Klaus01]

.. wenn Du mit XE5 arbeitest, das kennt meines Erachtens noch keine Inline Variable.

Delphi-Quellcode:

constructor TXorShift32.Create;
begin
{$IFDEF MSWINDOWS}
  var C: Int64;
  if QueryPerformanceCounter(C) then
    FSeed := UInt32(C)
  else
{$ENDIF}
    FSeed := TThread.GetTickCount;
end;

nach

Delphi-Quellcode:

constructor TXorShift32.Create;
  var C: Int64;
begin
{$IFDEF MSWINDOWS}
  if QueryPerformanceCounter(C) then
    FSeed := UInt32(C)
  else
{$ENDIF}
    FSeed := TThread.GetTickCount;
end;

ändern.

Grüße
Klaus

[Andreas13]

Vielen Dank Klaus für Deinen Hinweis! :thumb: Das Kompilieren hat zwar geklappt, aber nach Umschreibung der Inline-Variablen auf "ordentlich deklarierte" erhalte ich in den Demos / Samples diverse Speicherlecks, die ich nicht bereinigen konnte.

Verstehe nicht, warum solche Inline-Deklarationen wie z. B. in BigMathConstants.dpr gut sein sollen:

Delphi-Quellcode:

var EulerDigits := 500; // welcher Type ist das eigentlich? Integer, Word, UInt64... ?
..
var CalcEuler := Euler(EulerDigits);
..
var CheckEuler := TFile.ReadAllText('..\..\..\Samples\MathConstants\Euler10k.txt');

var firstError := CheckDigits(calcEuler.ToString, CheckEuler);

Davon wird der Code nur chaotisch, nicht unbedingt besser, und manchmal sogar nicht einmal eindeutig...:gruebel:

[edit]:
oder gar sowas

Delphi-Quellcode:

for var idx := 1 to Length(Digits1) do // Digits1 ist ein String
...

[Uwe Raabe]

Das hängt sicher auch von der Art des Einsatzes von Inline-Variablen und vom persönlichen Geschmack ab.

Gerade das automatische Ermitteln des Typs ist in vielen Fällen ganz hilfreich (z.B. wenn der Rückgabetyp einer Funktion sich ändert) und erübrigt manchmal sogar das Hinzufügen einer Unit in der Uses-Clause um lediglich Zugriff auf die Typdeklaration zu bekommen.

Mittlerweile verwende ich in for-Schleifen fast nur noch Inline-Variablen, da diese im Scope auf die Schleife beschränkt sind.

Delphi-Quellcode:

for var idx := Low(arr) to High(arr) do
...

passt halt zu jedem Array-Index. Genauso wie

Delphi-Quellcode:

for var element in arr do
...

zu jedem Elementtyp passt.

Nebenbei, aus Sicht des Compilers ist immer Eindeutigkeit gewährleistet.

[Andreas13]

Du hast recht Uwe: in Schleifen wünschte ich mir auch schon lokal gültige Inline-Variablen, aber mit einer "anständigen" Deklaration...

Kann der Speicherleck von meiner Umstellung auf herkömmliche Deklarationen kommen?

[himitsu]

Zitat:

Delphi-Quellcode:

for var idx := 1 to Length(Digits1) do

Gerade das hat aber einen enormen Vorteil.

Hier kann niemand mehr auf die saublöde Idee kommen jene Variable nach der Schleife noch benutzen zu wollen. :freak:




Und wenn man sich Inline-Variablen wie ein WITH vorstellt, dann kann es auch nett sein.
Aber egal ob globa, lokall oder inline, ist alles besser, als WITH,
aber beim Inline finde ich es besser, da auch mal in einer größeren Funktion einbuchstabig zu arbeiten (immerhin macht man ja das WITH, zum faulen Platzsparen), wenn diese Variable nur in einem abgegrenzten Teil benutzt wird.

Da lässt sich auch in mehreren Schleifen oder IFs, bzw. BEGIN-END-Blöcken der selbe Buchstabe nutzen, und dennoch ist theoretisch erkennbar, dass es unterschiedliche Inhalte sind.


Oder speziell für einen kurzen Debugcode (Debug-&Loggingausgabe), der sich z.B. über ein IFDEF an-/abschalten lässt, da kann eine dort benötigte Variable auch wirklich nur dort deklariert werden.

[Andreas13]

Könnt Ihr BigNumberVisualizers.dpr kompilieren? Dort sind zwar keine Inline-Deklarationen, aber anscheinend ein anderes Problem:

[dcc32 Fehler] Velthuis.BigIntegers.Visualizers.pas(96): E2065 Ungenügende Forward- oder External-Deklaration: 'TDebuggerBigIntegerVisualizer.GetSupportedType'
[dcc32 Fataler Fehler] BigNumberVisualizers.dpr(9): F2063 Verwendete Unit 'Velthuis.BigIntegers.Visualizers.pas' kann nicht compiliert werden

:gruebel:

[Klaus01]

Hi Andreas,

mit Delphi 10.4.2 compiliert das ganze, zuerst musste BigNumbers erzeugt und installiert werden.
Wenn es mit Deinen geänderten Source nicht funktioniert - wäre es, glaube ich, zielführender diese hier einzustellen.

Grüße
Klaus

[Andreas13]

Hi Klaus,
das Kompilieren von package BigNumbers.dproj scheitert bei mir an der Zeile:
{$LIBSUFFIX AUTO}
[dcc32 Fehler] BigNumbers.dpk(28): E1030 Ungültige Compileranweisung: 'LIBSUFFIX'
:(

[himitsu]

AUTO ist neu ... damit können aktuelle Delphis selbstständig/automatisch "ihre" PackageVersion da eintragen/benutzen

Delphi-Quellcode:

{$LIBSUFFIX '190'}

erzeugt ein Package mit dem Suffix für XE5 ... in XE6 kompiliert mit dem selben Suffix, außer DU schreibst da 200 hin.
BigNumbers190.bpl

[Andreas13]

XE5 versteht auch noch kein {$LIBSUFFIX 190}

[Uwe Raabe]

Es muss ja auch {$LIBSUFFIX '190'} heißen

[himitsu]

Niemand hätte dir verboten in die Hilfe zu schauen :zwinker:
https://docwiki.embarcadero.com/RADS...jects_(Delphi)
https://docwiki.embarcadero.com/RADS...iler-Versionen

Sorry, bei manchen Direktiven ist das ' optional ... hier leider nicht. :oops:

[Klaus01]

.. kannst Du mal {LIBSUFFIX auto} mit {$LIBSUFFIX '270'} oder {$LIBSUFFIX '190'} austauschen - keine Ahnung ob das bei XE5 funktioniert.
auto kannte XE5 noch nicht.

Grüße
Klaus

[Andreas13]

Danke Uwe! Es geht zwar weiter, kommen aber fehlende Dateinen.
Was heißt eigentlich die Compiler-Warnung:
[dcc32 Warnung] BigNumbers.dpk(42): W1007 Unit 'Velthuis.BigRationals' ist experimentell

[Klaus01]

.. das ist eine Warnung - compilieren sollte es trotzdem.

[Andreas13]

Danke, aber es scheinen Dateien zu fehlen. Ich suche weiter.:-D

[himitsu]

Die Warnung: Schau mal ganz oben, hinter das UNIT, in der Velthuis.BigRationals.pas


Oder es fehlen Suchpfade.

[Andreas13]

Beim Kompilieren von package BigNumbers.dproj oder BigNumbers.dpk
bekomme ich die Fehlermeldung:

Package BigNumbers$(Auto).bpl kann nicht geladen werden.
Das System kann die angegebene Datei nicht finden
[Fataler Fehler] Package BigNumbers$(Auto).bpl kann nicht geladen werden.
Das System kann die angegebene Datei nicht finden

[Andreas13]

Danke Himitsu, das "experimental" habe ich inzwischen entdeckt. Heiß es, daß es nicht unbedingt funktionieren muß? :-D

[Andreas13]

Ich mußte von XE5 aus BigNumbers.dproj und BigNumbers.dpk neu erstellen, und erst dann konnte ich es kompilieren & installieren. Anscheinend war etwas "Neues & Unbekanntes" in der Projektdatei, was alles blockiert hat. :wall:
Danke für Eure Hilfe und wertvollen Tipps! :cheers:

Ich teste weiter... :coder2:

[himitsu]

experimental ist wie deprecated eine bloße Markierung.
Einmal dass etwas alt ist und zukünftig nicht mehr benutzt werden "sollte", weil es z.B. vermutlich bald rausfliegt.
Und andersrum dass etwas neu ist und noch nicht für die "normale" Verwendung empfohlen wird, da z.B. ungetestet, noch nicht fertig und könnte sich eventuell nochmal grundlegend verändern werden.

Drauf hören muß man nicht unbedingt, aber ...



Oder die Warnungen bezüglich platform, damit man aufpasst, dass es in anderen Plattformen (iOS/Linux/Android/...) eventuell nicht verfügbar ist, falls man mal auf die Idee kommen sollte sowas versuchen zu wollen.

[Andreas13]

Ich konnte BigNumbers.dpk zwar kompilieren & installieren, aber das ganze Spiel beginnt von vorne, wenn ich BigNumVisualizers.dproj und BigNumVisualizers.dpk versuche zu kompilieren:
[dcc32 Warnung] Velthuis.BigRationals.pas(167): W1025 Sprach-Feature wird nicht unterstützt: 'class constructor'
[dcc32 Warnung] Velthuis.BigRationals.pas(333): W1025 Sprach-Feature wird nicht unterstützt: 'operator explicit'
... ca. 20-mal
[dcc32 Warnung] Velthuis.BigDecimals.pas(512): W1025 Sprach-Feature wird nicht unterstützt: 'operator explicit'
[dcc32 Fehler] Velthuis.BigIntegers.Visualizers.pas(96): E2065 Ungenügende Forward- oder External-Deklaration: 'TDebuggerBigIntegerVisualizer.GetSupportedType'
[dcc32 Fataler Fehler] BigNumVisualizers.dpk(41): F2063 Verwendete Unit 'Velthuis.BigIntegers.Visualizers.pas' kann nicht compiliert werden
obwohl ich BigNumVisualizers.dproj und BigNumVisualizers.dpk von XE5 erstellen ließ. Wahrscheinlich ist die Bibliothek nur für neueste Delphi-Versionen geeignet.

Darüber hinaus steht in https://github.com/TurboPack/RudysBi...ki/BigDecimals
„Currently, there are no functions that provide higher mathematical functions (except Sqrt) for BigDecimals. I intend to write a new unit that provides functions like Cos, ArcTan, SinH, Ln, Exp or Pi with a set precision, but that is still in the planning stage.“

Ich glaube, ich gebe auf, denn es scheint nicht noch ausgereift zu sein :(, und bleibe doch bei Gammatester’s (= Wolfgang Ehrhardt) zwar viel komplizierteren, jedoch funktionierenden MPA-Bibliotheken... :thumb:

Danke für Eure Hilfe!

[Uwe Raabe]

Zitat:

Zitat von Andreas13 (Beitrag 1522422)

denn es scheint nicht noch ausgereift zu sein

Das ist halt nicht für so alte Delphi-Versionen gedacht.

Du kannst ja alternativ mal den Originalcode von Rudy probieren: https://github.com/rvelthuis/DelphiBigNumbers

[Andreas13]

obwohl es in jeder Unit steht: "Language: Delphi version XE2 or later" :(

[himitsu]

Klingt so, als wenn immer jeder Entwickler nicht nur den Code radikal umbaut, sondern auch gleichzeitig die Dokumentation anpassen würde. :roll:

[jaenicke]

Zitat:

Zitat von Andreas13 (Beitrag 1522422)

[dcc32 Warnung] Velthuis.BigRationals.pas(167): W1025 Sprach-Feature wird nicht unterstützt: 'class constructor'
[dcc32 Warnung] Velthuis.BigRationals.pas(333): W1025 Sprach-Feature wird nicht unterstützt: 'operator explicit'

Das gab es bei XE5 auch schon. Die Warnungen kommen daher, dass in dem Projekt in den Projektoptionen unter Delphi-Compiler --> Ausgabe - C/C++ --> Erzeugung der C/C++-Ausgabedatei etwas anderes als "Nur DCUs erzeugen" drin steht. C++ kennt diese Sprachkonstrukte nicht (bzw. kannte sie in XE5 zumindest nicht), so dass es bei Erzeugung der C++ Dateien diese Warnungen gibt.

Deshalb kommt auch eine valide Warnung zu einem Sprach-Feature, denn wenn der Compiler dieses nicht kennen würde, würde er den Bezeichner bemängeln.

Das Problem ist also nur "Ungenügende Forward- oder External-Deklaration: 'TDebuggerBigIntegerVisualizer.GetSupportedType'". Da musst du mal schauen. Ich sehe da auf den ersten Blick kein Problem.

// EDIT:
Ach so, doch, das {$IFDEF GENERICS} steht nur unten bei der Implementierung, nicht aber oben in der Interface-Deklaration...
GENERICS erst ab Delphi 10.2 hätte ich nun nicht erwartet.

Heißt:
Einfach oben die bemängelte Deklaration auch in das IFDEF packen. Dann klappt es auch noch mit XE2.

[DenkDirNix]

Zitat:

Zitat von Uwe Raabe (Beitrag 1522401)

...und erübrigt manchmal sogar das Hinzufügen einer Unit in der Uses-Clause um lediglich Zugriff auf die Typdeklaration zu bekommen.

Das ist ja cool. Wie löst der Compiler das dann ???

[jaenicke]

Zitat:

Zitat von DenkDirNix (Beitrag 1522431)

Zitat:

Zitat von Uwe Raabe (Beitrag 1522401)

...und erübrigt manchmal sogar das Hinzufügen einer Unit in der Uses-Clause um lediglich Zugriff auf die Typdeklaration zu bekommen.

Das ist ja cool. Wie löst der Compiler das dann ???

Durch Type Inference. Er ermittelt bei einer solchen Deklaration zunächst den Typ des Rückgabewerts und übernimmt den dann für die Variable. Die Unit dazu braucht er dann nicht selbst in der uses, da er den Typ ja bereits kennt und nicht ermitteln muss.

Genau das kann aber auch nicht sofort zu findende Kompilierfehler auslösen, weshalb ich kein Freund davon bin. Wenn man z.B. eine fremde Unit eingebunden hat (aber natürlich auch bei eigenen) und dann ein Update einspielt, kann es sein, dass sich der Typ des Rückgabewerts dort ändert. Nun übernimmt der Compiler klaglos den neuen Typ. Erst bei der späteren Verwendung der Variablen gibt es dann ggf. einen Fehler. Wenn man nun nicht genau im Kopf hat, welcher Rückgabetyp da vorher kam, wundert man sich erst einmal. Wenn man aber den Typ explizit angegeben hat, sieht man direkt, dass das nun ein anderer Typ ist.

Ja, in Schleifen sind Inline Variablen durchaus praktisch und haben auch den Vorteil des eingeschränkten Scopes.

Wer aber Inline Variablen nutzt, um nicht zur Deklaration scrollen zu müssen, hat einfach zu lange Methoden...

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1522432)

Wer aber Inline Variablen nutzt, um nicht zur Deklaration scrollen zu müssen, hat einfach zu lange Methoden...

Ich benutze mittlerweile auch recht oft sowas (auch wenn die Methode nur dieses Konstrukt enthält):

Delphi-Quellcode:

var myInstance := TMyObject.Create;
try
...
finally
  myInstance.Free;
end;

Will ich den Typ ändern, muss ich das nur an einer Stelle tun. Oft starten solche Konstrukte mit TStringList, die über ein TDictionary später zu einer Spezialklasse mutiert.

Natürlich ist das keine große Sache und Sync-Edit hilft ja auch schon viel, aber ich finde das einfach eleganter.

Wenn ich mal gute Laune habe, spendiere ich auch noch ein bedingungsloses begin/end, um wie beim for-loop den Scope einzugrenzen.

[himitsu]

Gut, beim Schreiben der Variable gibt es für Inline alleine keinen Vorteil (abgesehn von dem Vorteil der Typinferenz und eventuell unnötigem Uses).
aber man kann auch das VARiablen-Makro benutzen und eine lokale Variable inline deklarieren.

[jaenicke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1522440)

Natürlich ist das keine große Sache und Sync-Edit hilft ja auch schon viel, aber ich finde das einfach eleganter.

Ich sage ja auch nicht, dass es nicht eleganter ist. Nur überwiegen für mich die Nachteile.

[Andreas13]

Bei BigNumVisualizers.dpk habe ich alle zuvor genannten Tipps befolgt:

Zitat:

Zitat von jaenicke (Beitrag 1522427)

...Die Warnungen kommen daher, dass in dem Projekt in den Projektoptionen unter Delphi-Compiler --> Ausgabe - C/C++ --> Erzeugung der C/C++-Ausgabedatei etwas anderes als "Nur DCUs erzeugen" drin steht...
... das {$IFDEF GENERICS} steht nur unten bei der Implementierung, nicht aber oben in der Interface-Deklaration... Einfach oben die bemängelte Deklaration auch in das IFDEF packen. Dann klappt es auch noch mit XE2.

Delphi-Quellcode:

...
Implementation
...
hinzugefügt:
{$IF RTLVersion >= 32.0}
  {$DEFINE GENERICS}
{$IFEND}

Trotzdem bekomme ich diese Felhermeldung:
[dcc32 Fehler] Velthuis.BigIntegers.Visualizers.pas(112): E2065 Ungenügende Forward- oder External-Deklaration: 'TDebuggerBigIntegerVisualizer.GetSupportedType'
[dcc32 Fataler Fehler] BigNumVisualizers.dpk(36): F2063 Verwendete Unit 'Velthuis.BigIntegers.Visualizers.pas' kann nicht compiliert werden

Der wichtige Hinweis in https://github.com/TurboPack/RudysBi...ki/BigDecimals
"Derzeit gibt es keine Funktionen, die höhere mathematische Funktionen (außer Sqrt) für BigDecimals bereitstellen. Ich beabsichtige, eine neue Unit zu schreiben, die Funktionen wie Cos, ArcTan, SinH, Ln, Exp oder Pi mit einer bestimmten Genauigkeit bereitstellt, aber das ist noch in der Planungsphase."
ist für mich bereits ein KO-Schlag, denn ich brauche in meinen Anwendungen viel meeeeeeeeehr als nur +, -,* und /... :(

Danke Euch allen für Eure wertvollen Tipps & die lehrreiche Diskussion! :thumb: :-D

[himitsu]

Zitat:

trotzdem

Vielleicht besser lesen?

Unten (Implementation) steht eine Funktion innerhalb eines

Delphi-Quellcode:

{$IFDEF GENERICS}

also muß oben im Interface DIESES auch in ein IFDEF rein.

[Andreas13]

:oops: :oops: :oops:

[himitsu]

Ansonsten, ist dieses DEFINE auch etwas ungünstig benannt (vom dem, der das dort eingebaut hatte),
denn Generics gibt es schon viel länger. (im Delphi seit 2009 und Delphi.Net seit 2007)

Vermutlich meinte der Entwickler nur einen gewissen Teil von/mit Generics, welcher erst ab dieser Version existiert.

[Stevie]

Das ist wieder typisch für ein Opensource Projekt, was unter Embarcaderofuchtel gepflegt wird. Denen ist das immer Wurscht, obs noch mit älteren Versionen kompatibel ist :roll:

[BerndS]

Zitat:

Das ist wieder typisch für ein Opensource Projekt, was unter Embarcaderofuchtel gepflegt wird. Denen ist das immer Wurscht, obs noch mit älteren Versionen kompatibel ist

Der aktuellen Version von VirtualStringTree geht es da auch nicht besser. Bei XE7 verursacht die Zeile in unit VirtualTrees:

Delphi-Quellcode:

 
  ...
  TBaseVirtualTree = VirtualTrees.BaseTree.TBaseVirtualTree;
  ...

einen Interner Fehler URW 1163. (Da hift dann nur noch Neustart der IDE)
Hier hilft es bereits, diese auszukommentieren um es unter XE7 zum Laufen zu bringen.

[himitsu]

Zitat:

Zitat von Andreas13 (Beitrag 1522397)

Halllo Community,
am 7. Apr 2023 konnten wir im Beitrag https://www.delphipraxis.net/212826-...pi-delphi.html erfahren, daß Rudy's Big Number library https://github.com/TurboPack/RudysBigNumbers erfreulicherweise weitergepflegt wird. :-D

TurboPack ... warum nicht gleich dran gedacht.

Probier doch mal die Version im GetIt, zur jeweiligen Delphiversion.
Ich hoffe mal jemand hat auch das getestet, dass es kompiliert, was er da rein tut. :stupid:

[Andreas13]

Sorry, Himitsu, ich habe in XE5 keinen GetIt Package Manager. Wo kann ich den bekommen?