case .. of kann kein break - Gibt es dafür einen rationalen Grund?

[Sherlock]

Zitat:

Zitat von Der schöne Günther (Beitrag 1536484)

Das hat doch nichts mit Scopes zu tun - Ein break verlässt eine Schleife. Ein case ist keine Schleife. Ich käme auch nie auf die Idee, ein „if/else“ mit break verlassen zu wollen.

Damit dürfte des Kopfes Nagel getroffen worden sein. Andererseits...if-Schleife...hmmmm :stupid:

[Rollo62]

Zitat:

Zitat von hannsg (Beitrag 1536486)

Die "reine Lehre" sagt wohl, dass jeder Block nur genau einen Eingang und genau einen Ausgang haben darf. Daher ist sowas im ursprünglichen Pascal nicht enthalten...

Gruß, Meik

Das bleibt doch auch so.
Aber ja, es gibt dann versciedene Pfade.
Die gibt es durch if then else, case usw. auch schon.

Und ja, "break" ist in Pascal für Schleifen da.
Vermutlich sollte ich im C-Formum mal danach fragen.

Zitat:

Zitat von Uwe Raabe (Beitrag 1536482)

Standard Pascal nach Jensen/Wirth kennt dieses Break gar nicht. Eingeführt wurde es um Schleifen vorzeitig bzw. unabhängig von der Schleifenbedingung abzubrechen. Ein Verlassen des Scopes mit Exit gibt es (neben Goto, geht aber nicht immer) nur bei Methoden, Prozeduren und Funktionen. Das case-Konstrukt gehört in keine dieser Kategorien.

Ja, ein Exit verlässt eine Methode/Prozedur/Funktion, also auch den Scope eben dieser.
Na gut, wenn ich innerhalb einer Methode extra Scopes mit begin ... end aufmache, dann verlässt ein Exit immer noch die ganze Methode.

Du stimmst mir hoffentlich zu, das innerhalb eines cases auch ein "Scope" existiert.
Klar kann ich da auch mit Exit; raus.

Zitat:

Zitat von Uwe Raabe (Beitrag 1536482)

Ich würde auch kein break innerhalb des case haben wollen. Dazu benutze ich es zu gern zum Abbruch einer darum liegenden Schleife.

Das Problem hat man in C natürlich auch.

Die meisten Erklärungen bis jetzt sind aber nur persönliche Befindlichkeiten oder Abneigungen, aber bis jetzt kein echter Informatik-lastiger Grund,
wieso ein frühzeitiger Abbruch eines case ... of Scopes irgendwie schädlich sein könne.
Der Beweis wäre das es mit goto geht, wahrscheinlich muss ich bei den Gründen nach den Abneigungen gegen goto suchen (Spagetti-Code). :stupid:

[himitsu]

Nochmal zusammengefasst:

• CASE im Pascal ist eine JumpList, welche in die einzelnen CASEs springt, nur den Einen ausführt und automatisch abbricht (zum Ende springt).
• In C-Sprachen wird beim CASE an den Anfang des Gewünschten gesprungen und ab da wird ALLES ausgeführt, es sei denn mit BREAK wird abgebrochen..
• BREAK im Pascal/Delphi bricht nur Schleifen ab, also FOR, WHILE und REPEAT.

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1536474)

Delphi-Quellcode:

  case LMyVariable of
     TMyVariable.One: X := 1;
     TMyVariable.Two      : begin

                                Mache1;

                                if MyCondition then
                                begin
                                    Mache2;
                                end;

                            end;
     TMyVariable.ThreeBlue: begin

                                Mache1;

                                if not MyCondition then
                                begin
                                    break;                 //<== DAS GIBT ES LEIDER NICHT =================
                                    goto CaseBreakLabel;   //<== Wäre die einzige rationale Verwendung von goto, mach ich aber trotzdem nicht 
                                end;

                                Mache2;

                            end;
     else
                            begin
                            end;
  end;
  
CaseBreakLabel:

  HierGehtsWeiter;

In deinem Beispiel wäre das break als Scope-Exit des case-Statements ja auch willkürlich gewählt. Man könnte es auch so interpretieren, dass es ein Exit des then-Zweigs oder des begin-end Block des case Labels ist (was in diesem Fall wiederum äquivalent zum case wäre). Irgendwo muss dann aber beim break der Scope definiert sein, der damit verlassen wird. Bei einer Schleife ist das noch ersichtlich: es ist die innerste Schleife im aktuellen Scope. Bei der Vielzahl möglicher Scopes in Pascal wäre das doch total unübersichtlich.

Wie schon gesagt, ich bin mit der Definition ein break bricht die innerste Schleife im Scope ab ganz zufrieden. Alles darüber hinaus wäre nicht nur schwerer zu durchschauen, sondern kann auch bei einer simplen Änderung des Codes völlig anders verlaufen (z.B. wenn man das

Delphi-Quellcode:

if not Condition then...

mit einem weiteren case-Konstrukt oder einer Schleife umschließt). Das ist ja schon jetzt bei Schleifen zu beachten. Ohne eine syntaktische Möglichkeit den zu verlassenden Scope anzugeben wäre das nur sehr schwer zu warten.

[himitsu]

Zitat:

Delphi-Quellcode:

                                if not MyCondition then
                                begin
                                    break; //<== DAS GIBT ES LEIDER NICHT =================
                                    goto CaseBreakLabel; //<== Wäre die einzige rationale Verwendung von goto, mach ich aber trotzdem nicht
                                end;

                                Mache2;

Delphi-Quellcode:

                                if MyCondition then
                                begin
                                    Mache2;
                                end;

Erstmal kein Break notwendig,
erspart auch gleich die unnötige Negierung
und man erkennt sofort, dass es eigentlich identisch mit Two ist. :stupid:

[himitsu]

Man könnte vielleicht mal einen Feature-Request stellen, für ein neues CASE, welches c-iger arbeitet,
also ohne Implizites und dafür optional mit manuellen BREAKs.

[Rolf Frei]

Ich glaube die lachen dich dann für den Feature Request aus. Komplett unnötig.

[QuickAndDirty]

Rollo62 warum kann ich den Scope von einer IF THEN Anweisung nicht mit break verlassen?
WAAAAARUMMMM?

Delphi-Quellcode:

For var i:integer := low(Werte) to High(Werte) do
Begin
  case Werte[i] of
    TWert.wGut: DoWert_gut;
    TWert.wSchlecht: DoWert_schlecht;
    TWert.wVerseucht:
      Begin
        Showmessage('Alles unbraucbar!');
        break; //Welches verhalten erwartest du hier?
      end;
    else
      DoWert_unspezifisch;
  end;
end

[freimatz]

Die Lehre der Strukturierte Programmierung :lol:

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1536491)

Irgendwo muss dann aber beim break der Scope definiert sein, der damit verlassen wird.

Ja gut, wie gesagt, bei C gibt es das gleiche Problem, dass ein break nicht für eine außenliegende Schleife zuständig ist.
Oder besser gesagt, dass break wäre in diesem Fall IMMER für das case .. of zuständig, und nicht für die außenliegende Schleife.

Ok, zumindest könnte man sagen, dass dies ein halbwegs plausibler Grund gegen break im case wäre.

Man könnte aber auch so argumentieren:

Delphi-Quellcode:

 case LMyVariable of
     TMyVariable.One: X := 1;  //<= HIER ist de facto ein "BREAK", Ende des case statements

     TMyVariable.ThreeBlue: begin
                                Mache1;

                                if not MyCondition then
                                begin
                                    break; //<= HIER soll es kein "BREAK", Ende des case statements geben
                                end;

                                Mache2;

                            end;  //<= HIER ist de facto ein "BREAK", Ende des case statements
  end;

Zitat:

Zitat von himitsu (Beitrag 1536493)

Man könnte vielleicht mal einen Feature-Request stellen ...

! Ich hatte explizit im Anfage gesagt, dass ich keinen Feature-Request möchte.
Ich möchte nur die Gründe kennen, die dagegen sprechen.

Da hätte ich an Pfade oder Sprungoptimierungen gedacht, aber es scheint nur philosophische Gründe dagegen zu sprechen.
Eingeschlossen, wie oben, dass ein break dann das break einer außenliegenden Schleife wegnehmen würde.

Ok, ok, belassen wir es dabei.
Ich brauche keine alternativen Vorschläge dazu, ich hatte ja schon erklärt, dass ich gerne Guards einsetze,
statt tiefverschachtelter, unübersichtlicher if-then-else.

Wahrscheinlich macht es dann sowieso Sinn statt "begin end;" im case zu haben, besser eine spezifische Case-Funktion aufzurufen.