Nutzung der break Anweisung sinnvoll?

Ist die Nutzung der break Anweisung sinnvoll, oder hat diese vergleichbar zum Goto Befehl Nachteile?

Zeus

Schon mal geswitched ohne break? Isst ne Fallgruppe, ne?

Professioneller Code? schrieb:

Ist die Nutzung der break Anweisung sinnvoll, oder hat diese vergleichbar zum Goto Befehl Nachteile?

Das ist voll und ganz Situationsabhängig und hängt auch mit Gewohnheiten und Idiomen zusammen. In Ada beispielsweise ist die "loop-exit"-Schleife, also eine Endlosschleife, die mit einer "exit"-Anweisung verlassen werden kann, das Grundlegende Schleifengerüst und "while" und "for" werden als Vereinfachungen gesehen, während es eine fußgesteuerte Schleife nicht einmal gibt.

Warum sollte man beispielsweise eine For-Schleife nicht verlassen, sobald ihre Aufgabe erledigt ist? Iteriert man über zehntausende Objekte und findet das Ergebnis bereits beim dritten Objekt, ist ein Break durchaus angemessen. Man kann natürlich auch eine Kopfgesteuerte Schleife nehmen und manuell iterieren, aber ob das "besser" ist?

Das Break ist gerade dafür da, um Goto auf der einen und komplizierte Verrenkungen auf der anderen Seite zu vermeiden.

Verwende es, wenn der resultierende Code einfacher zu verstehen wird, oder zu Optimierungszwecken.

Shade Of Mine

Spaßiger Code schrieb:

Warum sollte man beispielsweise eine For-Schleife nicht verlassen, sobald ihre Aufgabe erledigt ist? Iteriert man über zehntausende Objekte und findet das Ergebnis bereits beim dritten Objekt, ist ein Break durchaus angemessen.

Da gibts dann so lustige Codes wie:

bool running=true;
for(int i=0; i<length && running; ++i) {
  if(do_something(i)) running=false;
}

Teilweise gibt es echt die aergsten verraenkungen weil irgendetwas als verboten angesehen wird.

rüdiger

Bei sehr strikten Codingguidelines (ala Misra C(++)) ist break verboten. Es wird da als problematisch angesehen, dass man den Kontrollfluss so nicht auf einen Blick sehen kann. Ich persönlich finde aber, dass es unleserlicher wird, wenn man versucht alles in eine Schleifenbedingung zu zwingen. Der Schleifenkörper (wie Funktionskörper im allgemeinen) sollte eh nicht sehr lang werden und viele Verschachtelungen haben. Dann sieht man auch ein break.

berniebutt

goto war gestern z.B. mit BASIC und sehr unübersichtlich. break ist der Ausstieg aus einer Schleife oder einem switch. Man muss schon wissen, was man damit macht, denn man unterbricht damit eine laufende Kontrollstruktur. Ist sinnvoll!

abc.w

und wer breaks überhaupt nicht mag, auch in switch-case Konstrukten, kann noch auf folgenden Trick zurückgreifen:

switch (a)
    {
        if (0) case 0: blabla();
        if (0) case 1: blublu();
    }

Und wer noch Mitleid mit dem Compiler hat, dass er zu viele Leerzeichen parsen soll, kann auch so was machen:

switch(a){
      if(0)case 0:blabla();
      if(0)case 1:blublu();}

oder noch besser:

switch(a){if(0)case 0:blabla();if(0)case 1:blublu();}

berniebutt

@abc.w Und morgen erklärt jemand, wie man ohne if auskommt?

berniebutt schrieb:

@abc.w Und morgen erklärt jemand, wie man ohne if auskommt?

switch (a)
    {
        while(false){ case 0: blabla();}
        while(false){ case 1: blublu();}
    }

Switch statements can often be replaced by polymorphism

abc.w schrieb:

switch (a)
    {
        if (0) case 0: blabla();
        if (0) case 1: blublu();
    }

Ich hoffe das ist Satire...

knivil

berniebutt schrieb:

@abc.w Und morgen erklärt jemand, wie man ohne if auskommt?

In Haskell braucht man es nicht.

volkard

knivil schrieb:

berniebutt schrieb:

@abc.w Und morgen erklärt jemand, wie man ohne if auskommt?

In Haskell braucht man es nicht.

In C++ auch nicht.
Aber es ist nett, sehr nett.

knivil schrieb:

berniebutt schrieb:

@abc.w Und morgen erklärt jemand, wie man ohne if auskommt?

In Haskell braucht man es nicht.

Patternmatching ist doch nur ein verkapptes if.

break ist doch nur was für Frickler.

SideWinder

9999999999999999999999999 schrieb:

knivil schrieb:

berniebutt schrieb:

@abc.w Und morgen erklärt jemand, wie man ohne if auskommt?

In Haskell braucht man es nicht.

Patternmatching ist doch nur ein verkapptes if.

Ich bin erst Haskell-Einsteiger, aber Guards sind ja auch nicht sonderlich weit weg vom if, oder?

MfG SideWinder

knivil

Also if ist ein Schluesselwort in den meisten Sprachen, in Haskell nicht. Patternmatching und Guards ist trotzdem ein anderes Konzept. Man kann damit if nachbilden, aber mit if eben nicht auf einfache Weise Patternmatching. Patternmatching ist weder ein verkapptes if noch so aehnlich, nur weil man mit einem geringen Teilaspekt dieses Konzeptes if ausdruecken kann.

Und wenn so daran geht, dann ist jedes if/break/while auch nur ein Test+Sprung in Assembler und auf Binaerebene nur 0en und 1en. Bitte, irgendwo muss man aber eine Trennlinie ziehen.

berniebutt

knivil schrieb:

Also if ist ein Schluesselwort in den meisten Sprachen ...

So wie andere Schlüsselworte wie for, while, break, goto, etc. auch!. Hatte nicht geahnt, dass meine 'flapsige Bemerkung' überhaupt ein solches Echo auslöst! Man nannte das früher 'Kontrollstrukturen zur Ablaufsteuerung' eines Programmes. Kann mir schwer vorstellen, dass man diese Dinge nicht braucht! Allein goto mit Sprungmarken sollte man tunlichst vermeiden oder auf den Ausstieg einer komplexen Funktion beschränken. WinApi-Programmierung ohne break ist auch schwer vorstellbar.

volkard

knivil schrieb:

Bitte, irgendwo muss man aber eine Trennlinie ziehen.

Sprachen mit if: gut
~-------Volkards Trennlinie---------------------~
Sprachen ohne if: böse

Shade Of Mine

knivil schrieb:

Also if ist ein Schluesselwort in den meisten Sprachen, in Haskell nicht. Patternmatching und Guards ist trotzdem ein anderes Konzept. Man kann damit if nachbilden, aber mit if eben nicht auf einfache Weise Patternmatching.

Sicher. Man braucht nur eine vordefinierte Funktion match().
Und fertig.

Patternmatching, zumindest in ocaml/f# (haskell kenne ich nicht gut genug) ist nichts anderes als ein fancy if. Das soll Patternmatching nicht herabwürdigen - patternmantching ist ein geniales Feature. Aber es ist kein anderes Konzept als if. Nur die Bedingung ist eben fancy statt simples true/false.

knivil

volkard schrieb:

knivil schrieb:

Bitte, irgendwo muss man aber eine Trennlinie ziehen.

Sprachen mit if: gut
~-------Volkards Trennlinie---------------------~
Sprachen ohne if: böse

simple
~-------knivils Trennlinie---------------------~
fancy