Bool-Variablen

[Frabbing]

Vielleicht wäre die Einführung von Boolean-Variablen sinnvoll, die als Schaltervariablen geeigneter sind als z.B. Integer, weil sie ja nur zwei Zustände kennen. Somit würde ein >>Inc variable<< reichen, um den Zustand zu wechseln, ohne zusätzliche Abfragen oder Modulo einbauen zu müssen.

[AHT]

Zitat von Frabbing

Vielleicht wäre die Einführung von Boolean-Variablen sinnvoll, die als Schaltervariablen geeigneter sind als z.B. Integer, weil sie ja nur zwei Zustände kennen. Somit würde ein >>Inc variable<< reichen, um den Zustand zu wechseln, ohne zusätzliche Abfragen oder Modulo einbauen zu müssen.

Kann man aber schon über not(variable%) machen.

[Frabbing]

Einen Workaround gibt es ja für alle Sachen...
Aber so eine Variable könnte man schon am Postfix erkennen. Gibt ja auch nicht wenige Programmsprachen, die Bools fest implementiert haben.

[Jac de Lad]

Ich muss Frank zustimmen aber ich muss auch Andreas zustimmen! Das Not() würde ich nicht einmal als Workaround ansehen, das ist eher nativ. Von daher sind Bools gar nicht sooooo notwendig. Meiner Meinung nach.

[Dietmar Horn]

Boolean-Variablen würde ich ebenfalls als Bereicherung für XProfan empfinden, zumal das sicherlich von Roland leicht zu implementieren wäre.

Wer Booleans nicht nutzen möchte, der kann sie ja unbeachtet links liegenlassen, wie andere xprofansche Sachen gegebenenfalls ebenfalls.

Gruß
Dietmar

[RGH]

Sicher ginge so etwas, würde XProfan aber sicher nicht schneller machen, da jedes Ergebnis nun auch eine Bool'sche Entsprechung braucht.

Aber das Schwierigste: Welches Postfix kann man noch nutzen? Es sollte schon recht einfach zu tippen sein. b° oder b§ (letzteres fällt aus, da das § nur auf der deutschen Tastatur einfach zu erreichen ist) .

Außerdem scheint mir der Nutzen eher gering.

Gruß
Roland

[Frabbing]

Wenn du so argumentierst, ist der Nutzen von Integer-Variablen (16 Bit) aber auch gering bis gar nicht vorhanden. Kann ich doch besser LongInts benutzen, bei gleicher Geschwindigkeit und größerem Datenumfang.
Die brauchen weniger Speicher (unmerklich), sagst du jetzt vielleicht... aber wären dann nicht Bytes (Char) noch besser gewesen als Integer? Char-Variablen fehlen ja leider auch, obwohl Bytes mit XProfan in Speicher geschrieben und gelesen werden können.

Sind nur Anregungen, Roland.

[RGH]

Zitat von Frabbing

Wenn du so argumentierst, ist der Nutzen von Integer-Variablen (16 Bit) aber auch gering bis gar nicht vorhanden.

Das ist richtig, deshalb werden sie intern auch als ein Typ behandelt. In einem 32-Bit-System sind Integer halt 32 Bit groß und nicht 16. Wenn es mal ein 64-Bit-Profan geben würde (aber ein 64-Bit-Delphi ist bei mir nicht in Sicht), müssten Integer dann auch 64 Bit groß werden.

Aber die wichtigste Frage nach dem Postfix hast Du nicht beantwortet.

Gruß
Roland

[p. specht]

Sollte sich das nicht nach den Möglichkeiten der Rechenhardware richten, sprich, dem 80487 (falls vorhanden), bzw. jetzt der integrierten FPU (immer vorhanden)? Immerhin macht die FPU doch die ganze Rechnerei ... äh... oder etwa doch noch nicht?

Gruss

P.S.: Intel bietet bekanntlich zur Nutzung der FPU eigene SW-Bibliotheken an,
(siehe Math-Kernel Library),die einfacheren gratis, die genaueren leider kostenpflichtig (299 € aufwärts)..

[Frabbing]

Postfix könnte sein: ² oder ³ oder ° oder vielleicht ~

[AHT]

...Rein positive Variablen würde ich da schon als etwas wichtiger ansehen - die Fehlen mir an allen Ecken und Enden...

[RGH]

Naja, dann am ehesten wohl das °, obwohl das auch ziemlich besch...eiden aussieht.

Inc und Dec würden natürlich nicht mit Bools funktionieren, da das reine Integer-Befehle sind. Zu einer Boolschen Variable kann man nichts addieren oder subtrahieren. (Auch Delphi verweigert das mit dem Hinweis auf einen nicht artgerechten Operator.) Es ginge nur "bool° = not(bool°)", "bool° = 0" und "bool° = 1". Soweit geht es aber auch mit Integer. Man könnte allerdings eine Fehlermeldung erzeugen wenn einer Bool dann ein nicht-boolscher Wert zugewiesen werden soll, etwa bei "bool° = 56". Und zur Vereinfachung könnte man noch die Systemvariablen °true und °false einführen ...

Im Moment habe ich da noch arge Zweifel, ob der Benefit (so er überhaupt vorhanden ist) den Aufwand rechtfertigt. Es gäbe da durchaus Variablentypen, die ich mir eher als sinnvole Erweiterung vorstellen könnte ... etwa zum Beispiel die von AHT angedeuteten vorzeichenlosen Varianten von Integer oder Longint ... oder ...

Gruß
Roland

Gruß
Roland

[Frabbing]

Inc und Dec würden natürlich nicht mit Bools funktionieren, da das reine Integer-Befehle sind. Zu einer Boolschen Variable kann man nichts addieren oder subtrahieren. (Auch Delphi verweigert das mit dem Hinweis auf einen nicht artgerechten Operator.)

Seufz, ich denke wohl doch manchmal zu "Assembler"...
Wenn Bools nicht mit Überlauf funktionieren, sind sie natürlich völlig sinnlos. Ist mir zwar nicht verständlich, warum das so sein muss (die anderen Variablentypen arbeiten doch auch mit Überlauf), aber ich muss es wohl akzeptieren. Also vergiss die Idee.

[Jac de Lad]

Zitat von RGH

Das ist richtig, deshalb werden sie intern auch als ein Typ behandelt. In einem 32-Bit-System sind Integer halt 32 Bit groß und nicht 16. Wenn es mal ein 64-Bit-Profan geben würde (aber ein 64-Bit-Delphi ist bei mir nicht in Sicht), müssten Integer dann auch 64 Bit groß werden.

64Bit-Integer hängen aber nicht von 64Bit-Betriebssystem ab. Delphi kennt schon ewig lange das Int64, das ich auch gerne in XProfan hätte, noch viel lieber als Bool. Aber das hatte ich schonmal angesprochen.

Jac

[RGH]

Zitat von Jac de Lad

64Bit-Integer hängen aber nicht von 64Bit-Betriebssystem ab. Delphi kennt schon ewig lange das Int64, das ich auch gerne in XProfan hätte, noch viel lieber als Bool. Aber das hatte ich schonmal angesprochen.

Jac

Hallo, ich rede hier vom generischen Typ INTEGER. Dass es ein INT64 gibt ist mir bekannt. Der generische Datentyp INTEGER hat immer die Breite des jeweiligen Betriebssystems bzw. Programmes. In einer 32-Bit-Programmiersprache ist er also 32 Bit breit und somit in der Verwendung identisch mit dem fundamentalen Datentyp LONGINT. So ist es in Delphi, C++ ... und XProfan.

Unabhängig davon könnte man natürlich auch im 32-bittigen XProfan einen 64bit-Integer als Datentyp einbauen. (Und schon jetzt könnte man sich eine Klasse schreiben, die diesen Typ zur Verfügung stellt und ihn in einem 8-Byte-Bereicxh speichert.)

Gruß
Roland