Kann Rudy's Big Number library nicht kompilieren…

[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.
Danke für Eure Hilfe und wertvollen Tipps!

Ich teste weiter...

[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...

Danke für Eure Hilfe!

[Uwe Raabe]

Zitat von Andreas13:

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.

[jaenicke]

Zitat von Andreas13:

[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 von Uwe Raabe:

...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 von DenkDirNix:

Zitat von Uwe Raabe:

...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 von jaenicke:

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.