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