Kann Rudy's Big Number library nicht kompilieren…

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

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.




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

[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

{$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

[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

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