otherwise anstelle else bei case

[Mathias]

Ich habe gerade ein neues reserviertes Wort entdeckt "otherwise":

Code: Alles auswählen

var
  i: integer;
begin
  i := 2;
  case i of
    0: begin
      ShowMessage('0');
    end;
    1: begin
      ShowMessage('1');
    end;
    otherwise // sonst else
    begin
      ShowMessage('>=2');
    end;
  end;  

Weis einer für was otherwise gut ist ?
Oder was ist der Unterschied zu else ?

[fliegermichl]

Die Dokumentation sagt, daß man statt else auch otherwise schreiben kann. Es macht keinen Unterschied.

[Winni]

Hi!

Otherwise ist original Pascal von N. Wirth.

Das else im case wurde von Turbo-Pascal eingeführt.

Eine der vielen Verhunzungen, die wir TP verdanken.

Inklusive der Mini-Sets, die nur 256 Elemente enthalten können.
UCSD-Pascal konnte 1979 (!!) schon 4096 Members in einem Set enthalten.

Und die Verkettung von strings per "+" ist ja wohl übelstes Basic.
Auch so eine TP-Erfindung.

Winni

[Mathias]

Und die Verkettung von strings per "+" ist ja wohl übelstes Basic.
Auch so eine TP-Erfindung.[quotel]
Was findest du daran so schlimm ?

Code: Alles auswählen

s := s + 'abc';

Oder wie willst du dies besser lösen ?

Das else im case wurde von Turbo-Pascal eingeführt.

Das ist eine Erklärung, aber schlecht finde ich das von TP nicht. "else" ist doch alternativ, so wie bei "if".

Inklusive der Mini-Sets, die nur 256 Elemente enthalten können.
UCSD-Pascal konnte 1979 (!!) schon 4096 Members in einem Set enthalten.

Dies könnte das FPC-Team sicher auch einbauen. Oder ist dies dann nicht mehr Delphi komform ?

Aber im Allgemeinen ist dies alles noch viel besser als C/C++.

[Winni]

Hi!

Zur Stringverkettung:

Seit den frühsten Pascal-Tagen gibt die function concat:

Code: Alles auswählen

ResultString := concat (str1,str2, [str3...strn] );

Zum else in case:

Wenn man das case in der Tiefe von vielen ifs hat, so ist es angenehm wenn man auf ein otherwise stößt - man weiß, wo man ist, zwischen vielen if then else.

Zu den Mini-Sets:

Seit dem Begin von Turbo-Pascal (1983) hühnern wir mit der 256-Elemente-Grenze rum, was auch im internatonalen Forum immer wieder bitterlich beklagt wird, Irgendwo haben die fpc-Macher große Sets versprochen, aber keinen Zeitpunkt erwähnt. Wird aber auch Zeit nach knapp 40 Jahren, wo wir 1979 schon mal deutlich weiter waren - siehe meine erste Mail.

Winni

[Winni]

Aber im Allgemeinen ist dies alles noch viel besser als C/C++.

Jo - aber das ist doch selbstverständlich ....

Und dafür der Merksatz:

In geschweiften Klammern stehen die Kommentare.
In allen Programmier-Sprachen.

Winni

[m.fuchs]

Seit den frühsten Pascal-Tagen gibt die function concat:

Code: Alles auswählen

ResultString := concat (str1,str2, [str3...strn] );

Das macht ja nichts. Inc gibt es auch schon eine Weile, trotzdem kann man auch mit + Zahlen addieren. Ich finde das nicht schlimm, dass der Operator für Stringverkettung der gleiche ist wie der für mathematische Addition. Bei einer typisierten Sprache sehe ich da keine Nachteile.

Zum else in case:

Wenn man das case in der Tiefe von vielen ifs hat, so ist es angenehm wenn man auf ein otherwise stößt - man weiß, wo man ist, zwischen vielen if then else.

Wenn man ein case verschachtelt zwischen vielen ifs hat, dann hat man ein ganz anderes Problem. Nämlich schlechten Code. Da hilft dann das otherwise auch nicht mehr so richtig.
Auch hier wieder die Frage: was ist so schlimm, wenn das gleiche Keyword in einem unterschiedlichen Kontext eine ähnliche Funktion hat? Ist im Gegenteil eher einfach zu merken.

[PascalDragon]

Weis einer für was otherwise gut ist ?
Oder was ist der Unterschied zu else ?

otherwise stammt ursprünglich aus ISO Extended Pascal und erfüllt genau die gleiche Funktion in einer case-Anweisung wie das Turbo Pascal else.

Otherwise ist original Pascal von N. Wirth.

Nein, das originale Pascal enthält keinen Alternativzweig für die case-Anweisung (siehe Niklaus Wirth - The Programming Language Pascal, Punkt 9.2.2.2). ISO Pascal enthält das auch noch nicht. Das wurde erst mit ISO Extended Pascal in der Form von otherwise eingeführt.

Inklusive der Mini-Sets, die nur 256 Elemente enthalten können.
UCSD-Pascal konnte 1979 (!!) schon 4096 Members in einem Set enthalten.

Das hat aber auch immer mit der Größe zu tun: ein Set mit 256 Elementen ist immer 32 Byte groß. Bei einem Set mit 4096 Elementen ist das entsprechend 512 Byte. Da Sets solcher Größe auf dem Stack übergeben werden ist das durchaus eine Hausnummer, die man bedenken muss.

[Winni]

Das hat aber auch immer mit der Größe zu tun: ein Set mit 256 Elementen ist immer 32 Byte groß. Bei einem Set mit 4096 Elementen ist das entsprechend 512 Byte. Da Sets solcher Größe auf dem Stack übergeben werden ist das durchaus eine Hausnummer, die man bedenken muss.

Hi!

Die frühen Versionen von UCSD-Pascal benötigten 64 kB RAM, die späteren 128 kB. Da wird in Zeiten von Maschinen mit RAM >= 16 Gigabyte ja noch etwas Platz auf dem Stack sein.

Winni

[af0815]

Vergiss nicht, das der fpc verdammt viele Plattformen kann und die müssen nicht unbedingt mit Speicher gesegnet sein.

[Socke]

Vergiss nicht, das der fpc verdammt viele Plattformen kann und die müssen nicht unbedingt mit Speicher gesegnet sein.

Ich hab noch einen STM32 zuhause rumfliegen. Da passen gerade mal 40 Sets mit 4096 Elementen in den Speicher. Den Stack muss man dann aber in den Flash auslagern .

[Winni]

Hi!

Also 512 Byte sind nur genau 2 mal string[255].

Nun mal nicht so tun, als ob wir gerade Ende der 70er sind und 64 kB RAM zur Verfügung haben.

Und da ging's ja auch, wie UCSD-Pascal gezeigt hat
.

Außerdem könnte man das ganze ja optimieren.
Wird ja heute schon gemacht.
Wenn weniger als 32 Elemente im Set vorhanden sind, wird das in ein DWord gepackt. Glaub ich.

Winni

[PascalDragon]

Außerdem könnte man das ganze ja optimieren.
Wird ja heute schon gemacht.
Wenn weniger als 32 Elemente im Set vorhanden sind, wird das in ein DWord gepackt. Glaub ich.

Ja, FPC nimmt immer die Mindestgröße, die benötigt wird (auch bei mehr als 32 Elementen). Aber es ging mir hier darum, wenn Leute die größeren Sets auch wirklich ausnutzen.