Wenn es geht (Codeoptimierung und so), dann macht CASE auch derartige Berechnungen.
Delphi-Quellcode:
case i
of
1: x := 1;
5: x := 2;
30: x := 3;
end;
// Pseudocode, den Delphi generieren könnte, so in etwa (die mathematik)
t := i;
dec(t);
if t = 0
then begin x := 1; exit;
end;
dec(t, 4);
if t = 0
then begin x := 2; exit;
end;
dec(t, 25);
if t = 0
then begin x := 3; exit;
end;
// wobei Delphi GOTOs exterm gern hat und es dann eher so aussehn könnte (im Assembler ist das DEC und CMP vom IF zusammengefasst)
t := i;
dec(t);
if t = 0
then goto 1;
dec(t, 4);
if t = 0
then goto 2;
dec(t, 25);
if t = 0
then goto 3;
goto 4;
1: x := 1;
goto 4;
2: x := 2;
goto 4;
3: x := 3;
//goto 4;
4:
Vom "Speicher" zur Laufzeit ist Konstante und Variable kein Unterschied.
Die Variable braucht aber anfangs bissl Zeit, zum Füllen,
und bei der Laufzeit sind es zwei Pointer ... zur Variable und von da zum Speicher, wo es bei einer echten Konstante nur ein Zeiger ist, der beim Start von Windows berehnet wird. (ReallocationTabelle, falls die EXE im
RAM verschoben wurde)
PS: 256 wird nicht reichen, denn
Unicode sind ja 2^16 und nicht 2^8.
Wobei man das auch auf 2^7 (
ASCII) und weniger kürzen/casten könnte, wenn man vorher den Bereich prüft.
if (Ord(C) < 256) and Byte(C) ......
Statt 64KB (Boolean/Char) könnten auch 8KB (1 Bit/Char) reichen,
aber vom Tempo kommt es bestimmt mit einem LongBool am Besten, da dort die CPU optimaler drauf zugreifen kann, auf einen "Integer" im
RAM.
array[0..$FFFF] of LongBool
Und ganz im Ernst, bei all dem platzverschwendenden Mist, den dir Delphi schon unterjubelt, fällt es bestimmt nicht auf, wenn man die paar 256KB als Daten in die EXE einkompiliert.
(Konstante, Ressource oder ganz böse als Assembler
DB versteckt)