Prüfen ob Variable existiert

[Lewi]

Hi Martin,
sorry, aber sieht wohl so aus, das mir ein aktuter Fall von preseniler Demenz attestiert werden kann.

[olaf870]

Liebe Hausfrau Schmitterlöw,

eine kleine Bemerkung zu ihren Vorschläge, die Wieterentwicklung von Xbase betreffend:

Aufgehend von dieser rudimentären Wissensbasis, kann ich jetzt eine Zielvorstellung für die Weiterentwicklung der Functionen Valtype() und Type() definieren:

1.) Es gibt nur eine! Funktion aber zwei Namen (Kompatibilität).

2.) Das zukünftige Valtype() liefert einen definierten Wert auch dann, wenn die Variable unbekannt, nämlich nicht deklariert wurde.

Halali, die Jagd ist eröffnet. Ich freue mich auf geistreiche Beiträge, als Futter für mein Gehirn

MfG -löw

Es wäre falsch, die Funktion valtype() und type zu mergen: Beide Funktionen arbeiten unterschiedlich.
Die Funktion type( string ) schaut in der Variablen-Tabelle, ob der genannte string dort eingetragen ist. Die Funktion valtype( local_var ) nimmt auf eine (quasi) physikalische Speicheradresse Bezug und braucht natürlich die Angabe einer solchen und nicht etwa einen Namen aus der Speichertabelle.

Ich für meinen Teil bin froh, daß es beide Funktionen gibt.

Wolle man diese Funktionen mergen, wäre das Resultat ein erheblich langsameres Xbase-Runtimesystem, da es faktisch dazu zwänge, lokale Variablen nicht mehr als Speicheradresse sehen zu können, sondern ebenfalls in Tabellen verwalten zu müssen, über die sie dann genauso aufwendig wie das bei den PUBLIC´s geschieht aufgelöst werden müssen.

Abschließend sei gesagt, daß es sich bei LOCAL´s nicht um echte physikalische Adressen handelt. Die Verwaltung der LOCAL´s ist nur im Vergleich zu der Verwaltung von PUBLIC´s erheblich einfacher organisiert und daher ca. 100 Mal schneller. Die Verwaltung von LOCAL´s als physikalische Speicheradresse würde den Zugriff auf dieselben nochmal um Faktor 1000 speigern. Einen zwingenden Grund, warum Xbase LOCAL`s nicht als echte Speicheradressen sieht, gibt es wohl nicht wirklich (Den Grund der leichteren Debugbarkeit und der sanfteren Abstürze lasse ich mal aussen vor).

Wenn wir Einfluss auf Xbase nehmen wollen, dann besser hier, damit die Kiste noch mal ein bischen schneller wird.

Gruß
Olaf

[brandelh]

Hallo,

von der Performance würde es viel bringen, wenn wir zu den normalen Xbase++ Variablen (alles kann gemischt werden und Zahlen aller Art) noch zusätzlich die Möglichkeit hätten streng typisierte LONG Integers zu erhalten. Für alles was keine Nachkommastellen braucht wäre das um Welten schneller und im Vergleich = 0 genauer.

Nun ja wird wohl noch eine Weile dauern ...

Um nur die Tippfehler in den Variablen Namen zu finden, gibt es schon heute Compilerschalter für strenge Überprüfung der Deklaration.

[Lewi]

Hallo Olaf,
ich stimme Deinen Gedanken zu. Wenn es eine zugenannte "Strict"-Variable geben würde, die typisiert werden müßte und vom Runtimesystem als Speicheradresse gehändelt wird, wäre auch ich dankbar.

Als Folge dessen könnte ein Programm in jeder Beziehung ungleich performanter werden. Dies gilt insbesondere für die GUI und nummerisch orientierten Anwendungen z.b. für Datenanalysen und Simmulationen.
Gruß Olaf

[olaf870]

Eine LONG INTEGER wäre schon mal ein guter Anfang.