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

[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 , 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 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 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?

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