inc bei ordinären Typen(kein Ende in sicht)

[snow]

Hallo

ich hab gerade etwas merkwürdiges bemerkt. Wenn ich einen Ordinären typ habe (z.B mit 4 Einträgen) Dann sollte doch nach dem 4 mal inc wieder der erste Eintrag an der reihe sein oder? Der erste ist ja schließlich der letzte Plus Eins. dem ist aber nicht so.
inc zählt einfach gnadenlos weiter und verursacht natürlich Fehler. ist dass normal?

Gruß snow

PS:// Wiso gibts kein Gegenteil von inc?

[Die Muhkuh]

Das Gegenteil von inc ist dec...

[snow]

Danke ich hatte mich schon gewundert....

Aber wiso ist

Delphi-Quellcode:

type Tmy123 = (eins,zwei,drei,vier);

var test : Tmy123;

begin

inc(test);
inc(test);
inc(test);
inc(test);

showmessage(inttostr(ord(test)));
end;

Nicht 0(eins)?

Gruß snow

[Namenloser]

Andersherum gefragt: Wieso sollte es 0 sein?
Btw: Du inkrementierst eine uninitialisierte Variable

[snow]

naja weil ich dachte, dass es niemals 4 sein kann... Bei mir is es aber 4.

nach Index = 3 sollte ja index = 0 folgen.

Gruß snow

[Namenloser]

Intern sind Enums Integer (vllt. auch Bytes, bin mir da jetzt nicht sicher, ist aber auch egal).
Also kann jedes Enum auch jeden Wert einer Integer-Variable annehmen. Die "Werte" sind eigentlich nix anderes als Konstanten.

[snow]

dass bedeutet, dass ein Enum also den wert 4 haben kann obwol es nur bezeichner von 0-3 hat.

naja ich habs jetz mit ner If ..else abfrage gelöst.

Gruß snow

[3_of_8]

Es sind übrigens ordinale Typen, nicht ordinär. ;)

Ein enum kann auch Werte außerhalb des Wertebereichs haben. Es ist deine Aufgabe, das zu verhindertn. ;)

IIRC sind enums übrigens normalerweise keine Integers, sondern Cardinals. Welcher Cardinal hängt von der Anzahl der Elemente ab. Bis 256 Elemente ist es ein Byte, bis 65536 Elemente ein Word usw. Wobei es vermutlich selten Fälle gibt, in denen 65536 Elemente überschritten werden.

Das gilt natürlich nur für enums, denen nicht spezielle Werte zugewiesen wurden. (Also z.B. (bla=42, wuppdi=123456)). Außerdem kann es sein, dass der Compiler in records oder Klassen je nach Ausrichtungsoptionen immer ein LongWord (d.h. 32 Bit Cardinal) draus macht.

[Chewie]

Meiner Meinung nach ist das durchaus ein Fehler. Klar sind Aufzählungsvariablen intern nur Zahlen - alles sind intern ja irgendwie Zahlen!

Aber auf einer höheren Abstraktionsebene definiert der Typ Tmy123 eine geordnete Menge von 4 Elementen, jede Variable dieses Typs kann genau ein Element dieser Menge als Wert haben. Inkrementiere ich das höchste Element der Menge, so soll entweder eine explizite Fehlersituation entstehen (eine Exception) oder die Menge ist zyklisch und es geht wieder vorne los.

Das wäre das, was ich semantisch erwarte.

Wenn ich das beschriebene Verhalten wollte, dann würde ich durch einen expliziten Cast auf Integer dem Compiler signalisieren, dass ich nicht an der semantischen Bedeutung des Wertes interessiert bin, sondern an dem numerischen Wert.

Aber offensichtlich dachten da die Designer der Sprache anders.

[inherited]

was passiert wenn du am ende dein test wieder mit eins vergleichst, also auf test=eins testest? Liefert das true?

[himitsu]

Nja, erstmal, was hindert dich daran selber für die gewünschte Reinfolge zu sorgen?

Delphi-Quellcode:

If test > High(Tmy123) Then test := Low(Tmy123)
Else Inc(test);

Das Ganze liese sich dann notfalls auch noch schön in eine neue Inc-Prozedur verpacken.

Außerdem, weißt du wie aufwenig der Code ('s kompilierte ASM-Ergebnis) würde, wenn die "Designer der Sprache" auf jeden Wertesprung eingehen würden?

... abgesehn davon, daß Erstens die Codeausführung schonmal schön langsam werden könnte (durch unmassen Abfragen wann wie weitergesprungen werden sollte)

und Zweitens, was wäre mit den Programmieren, welche soein Verhalten nicht wöllten?
(wer sagt denn, daß die "undefinierten" Werte nicht doch verwendet werden?)


PS: Schlimmer wird es, wenn man da mal selber die Werte festlegt :roll:, da kommt noch weniger das raus, was du willst.

Delphi-Quellcode:

type Tmy123 = (eins=1,zwei=4,drei=9,vier=100);

var test : Tmy123;

begin
  test := eins;  // für Alle die es initialisiert haben wollen (=1)
  inc(test);     // =2 und nicht 4(zwei)
  inc(test);     // =3 und nicht 9(drei)
  inc(test);     // =4 und nicht 100(vier)
  inc(test);     // =5 und nicht 1(eins)
end;

[3_of_8]

Bei aktivierten RangeChecks gibt sowas glaube ich sogar eine Exception, oder? Aber RangeChecks sind ja, aus dem oben erwähnten Grund, nur zum Debuggen gedacht: Sie sind furchtbar langsam.

[Chewie]

Zitat:

Zitat von himitsu

Außerdem, weißt du wie aufwenig der Code ('s kompilierte ASM-Ergebnis) würde, wenn die "Designer der Sprache" auf jeden Wertesprung eingehen würden?

... abgesehn davon, daß Erstens die Codeausführung schonmal schön langsam werden könnte (durch unmassen Abfragen wann wie weitergesprungen werden sollte)

und Zweitens, was wäre mit den Programmieren, welche soein Verhalten nicht wöllten?
(wer sagt denn, daß die "undefinierten" Werte nicht doch verwendet werden?)

Zu ersterem: Das von 1 unterschiedliche Inkrement wäre kein Problem - ob ein INC var oder ein ADD var, offset erzeugt wird, macht den Bock nicht fett. Lediglich die Sprünge, die beim Umbrechen entstehen, könnten Probleme bereiten. Eventuell würden hier aber Sprungtabellen Abhilfe schaffen.

Edit: Moment... es geht doch nicht so einfach, der Offset ist ja variabel :oops: Aber andererseits könnte ich damit leben, dass Aufzählungstypen mit Lücken langsamer sind bei gewissen Operationen als andere.


Und zu zweiterem: Wie oben erwähnt könnte das mit Typecasts auf reguläre Ganzzahltypen funktionieren. Wenn du einen typisierten Zeiger auf einen 4-Byte-Integer hast und diesen mittels Inc erhöhst, so wird auch nicht um 1, sondern um 4 Byte inkrementiert. Wenn du untypisierte Inkrementierung willst, kannst du den Zeiger in einen untypisierten Zeiger casten.
Analog könnte das auch mit den Aufzählungstypen gemacht werden.

[OldGrumpy]

Irgendwie habe ich noch Succ() und Pred() im Hinterkopf... Verhalten die sich bei Enums ggf. anders? Ich kanns gerade nicht testen weil unterwegs :)

[3_of_8]

Die sollten sich eigentlich genauso wie inc() und dec() verhalten.

[Chewie]

Ich hab hier leider auch kein Delphi installiert, aber es wär doch mal interessant, das herauszufinden. Jemand interessiert? :zwinker:

[generic]

grundsätzlich ist an dem verhalten nichts falsch, da die ordinalen intern als uinteger abgelegt werden.
allerdings wenn ihr die überlaufprüfungen an habt, sollte es nach dem letzten wert einen überlauf exception geben.
(also mit {$Q+} und {$R+} kompiliert)

ein umspringen auf den ersten wert, wie von euch erwartet, gibt es nicht.
das könnt ihr aber mit "mod" selbst erzeugen.