Mein Informatiklehrer sagt, dass

JustAnotherNoob

Ich würde den Lehrer nicht so vorschnell verurteilen.
Generell gibt es keine bösen Konstrukte, aber es ist vertretbar, wenn Lehrer so etwas vor den Schülern behaupten.
Und wenn ein Lehrer behauptet, dass break schlechter Stil ist um die Schüler dazu zu bringen break zu vermeiden finde ich das nicht unbedingt verkehrt, auch wenn ich zu der Fraktion gehöre, die break schreibt, bevor sie ein Flag für den Fall einsetzt.
unüberlegte breaks sind auf jedenfall unschön, wenn es ohne workarrounds wie flags auch ohne break geht ist das im Normalfall auch schöner.

Außerdem sei froh, dass dein Lehrer den Begriff Stil überhaupt kennt.

An alle Gegner von break: wie wollt ihr denn folgendes Problem sinnvoll lösen?

unsigned int a, b;
cin>>a;
cin>>b;
//a und b sind zwei Zahlen, zwischen denen die erste Primzahl ermittelt werden soll
for( ; a!=b; ++a)
{
    if( is_prim(a) ) break;
}

Sollte man dann lieber a=b setzen, wenn a eine primzahl ist? Dann hat man aber den Wert von a für weitere Berechnungen verändert. Oder die Schleife einfach weiterlaufen lassen und falls is_prim einmal wahr war, nicht wieder auf primzahlen prüfen? Dann wird Rechenzeit vergeudet. Oder eine weitere Variable in die Bedingung des SChleifenkopfes einbauen? Das verkompliziert den ganzen Code doch nur...

JustAnotherNoob

also wenn man deinen Code nur leicht modifizieren würde, dann so

for(; a!=b && !is_prim(a); ++a);

volkard

unsigned int a, b;
cin>>a;
cin>>b;
//a und b sind zwei Zahlen, zwischen denen die erste Primzahl ermittelt werden 
int fp=findFirstPrimeBetween(a,b);

int findFirstPrimeBetween(int min,int max)
{
   for(int i=min;i!=max;++i)
      if(is_prim(i))
        return i;
   return 0;
}

das meinte ich oben mit "return ist besser als break".

Simon2

sdhfhj schrieb:

...Gegner von break...

Habe ich in diesem Thread noch keinen gesehen.
Vielleicht solltest Du die Frage da stellen, wo Du welche findest.

Persönlich finde ich Deinen Code wirklich ein gutes Beispiel für überflüssiges break: Es gibt eine klare, eindeutige und leicht zu formulierende Abbruchbedingung für die Schleife (sogar in Abhängigkeit von der "Laufvariablen") ... wofür der liebe Gott einen eigenen Platz im for- oder im while-statement geschaffen hat.

Gruß,

Simon2.

Erhard Henkes

OK, nehmen wir ein gestelltes Schul-Beispiel:

#include <iostream>
using namespace std;

int main()
{
  for(int i=0; i <= 100; ++i)
  {
    if(i%2)
      continue;
    else
      cout << i << ' ';
  }

  cout << endl << endl;

  for(int i=0; i <= 100; ++i)
  {
    if(i%2)
      cout << i << ' ';
    else
      continue;
  } 
}

Wie müsste das alles optimal ohne continue aussehen? ... und was ist dann der konkrete Vorteil?

Schlechtes Beispiel. Wenn du continue einfach weglässt, ist das Ergebnis noch das Selbe

#include <iostream> 
using namespace std; 

int main() 
{ 
  for(int i=0; i <= 100; ++i) 
  { 
    if(!(i%2)) //einfach den ! operator verwenden
      //continue; 
    //else 
      cout << i << ' '; 
  } 

  cout << endl << endl; 

  for(int i=0; i <= 100; ++i) 
  { 
    if(i%2) 
      cout << i << ' '; 
    //else 
      //continue; 
  } 
}

Jester

Erhard Henkes schrieb:

OK, nehmen wir ein gestelltes Schul-Beispiel:
#include <iostream>
using namespace std;

int main()
{
  for(int i=0; i <= 100; ++i)
  {
    if(i%2)
      continue;
    else
      cout << i << ' ';
  }

  cout << endl << endl;

  for(int i=0; i <= 100; ++i)
  {
    if(i%2)
      cout << i << ' ';
    else
      continue;
  } 
}
Wie müsste das alles optimal ohne continue aussehen? ... und was ist dann der konkrete Vorteil?

Äh, wenn ich über die geraden Zahlen iterieren will schreib ich

for(int i=0; i<=100; i+=2)
{
}

und bei ungeraden halt

for(int i=1; i<=100; i+=2)

Dass das geschickter ist brauchen wir wohl nicht wirklich zu diskutieren, oder? Das ist imo ein typischer Fall von dem von Simon2 erwähnten "über die genaue Bedingung mach ich mir später noch Gedanken".

volkard

Erhard Henkes schrieb:

OK, nehmen wir ein gestelltes Schul-Beispiel:
for(int i=0; i <= 100; ++i)
  {
    if(i%2)
      continue;
    else
      cout << i << ' ';
  }
Wie müsste das alles optimal ohne continue aussehen? ... und was ist dann der konkrete Vorteil?

Naja, was ist Dir lieber?

for(int i=0; i <= 100; ++i)
  {
    if(istTeilbar(i,2))
      continue;
    else
      cout << i << ' ';
  }

oder

for(int i=0; i <= 100; ++i)
  {
    if(not istTeilbar(i,2))
      cout << i << ' ';
  }

Simon2

Hi,

also ich bin skeptisch, dass es ein "gutes Beispiel" für break/continue in Schleifen gibt, das gleichzeitig auch "klein" ist.
Da, wo ich wirklich die beiden wirklich gewinnbringend (oder "kleinstes Übel" ) gesehen habe, waren es immer sehr kompliziert verschachtelte Schleifen/Bedingungen, bei denen nur in ganz seltenen Spezialfällen größere Blöcke übersprungen werden sollten.
Eben Dinge, die sich nicht so einfach in einen if- oder else-Zweig packen lassen...

Gruß,

Simon2.

elise

seien wir froh, dass überhaupt noch c++ irgendwo unterrichtet wird, die tendenz ist eine andere...

Artchi

Ich stelle hier fest, das mehrheitlich dem Lehrer zugestimmt wird!

Meine pers. Erfahrung ist die, das ich außer in switch-case fast nie break einsetze, wenn dann nur, weil ich mir nicht viel Gedanken für eine Alternative gemacht habe! continue habe ich glaube ich in meinem Leben nur einmal benutzt... zum Ausprobieren.

tntnet

Also meiner Ansicht nach hat der Lehrer im Prinzip recht. Häufig deuten break oder continue auf schlechten Code hin. Aus pädagogischer Sicht ist ein solcher Hinweis daher angebracht.

Es gibt dennoch Situationen, in denen diese Konstrukte sinnvoll sind.

Ein sehr einfaches Beispiel wäre:

int z;
while (true)  // ist das unsauber?
{
  std::cout << "Bitte geben Sie eine Zahl zwischen 1 und 10 ein:";
  std::cin >> z;
  if (z >= 1 && z <= 10)
    break;

  std::cout << "Die Zahl " << z << " ist nicht zwischen 1 und 10.\n";
}

Ohne break hätte man ein Problem. Da müsste man die Bedingung 2 mal prüfen, was unschön ist:

int z;
do
{
  std::cout << "Bitte geben Sie eine Zahl zwischen 1 und 10 ein:";
  std::cin >> z;
  if (z < 1 || z > 10)
    std::cout << "Die Zahl " << z << " ist nicht zwischen 1 und 10.\n";

} while (z < 1 || z > 10); // 2. Prüfung

Dravere

@tntnet,

char const* const message = "Bitte geben Sie eine Zahl zwischen 1 und 10 ein:";
std::cout << message;

int z = 0;

while(!(std::cin >> z) || z < 1 || z > 10)
{
  std::cout << "Die Zahl " << z << " ist nicht zwischen 1 und 10.\n";
  std::cout << message;

  std::cin.clear();
  std::cin.ignore(std::cin.rdbuf()->in_avail());
}

Man kann sehr vieles umformen. Ich persönlich brauche continue fast nie, break ein wenig öfter, aber meistens schreibe ich Schleifen ohne break und continue .

break und continue allerdings einfach zu verfluchen und verbieten, wie es ca. der Lehrer gemacht hat, würde ich nicht. Zum Teil gibt es Schleifen, wenn man dort kein break einführen würde, dann würde die Schleifen-Bedingung viel zu komplex und unübersichtlich werden oder die Schleife weisst dann x-fache if -Verschachtelungen auf. Es gilt halt wie für alle Sprachmittel: "Überlege bevor du sie verwendest".

Grüssli

Ich stelle fest, dass Gegner von break und continue in diesem Thread keine Argumente bringen, sondern nur von ihrem ästetischen Empfinden berichten und/oder behaupten, es gäbe immer eine elegantere Schleifenvariante, die ohne break und continue auskommt. Letzteres ist natürlich schwer zu beweisen -- gerade auch weil Dijkstra und Knuth sich mit dem Thema auseinander gesetzt haben und zu dem Schluss gekommen sind, dass man mit goto s -- damals gabs noch kein break und continue -- in manchen Fällen Code-Duplikationen und "Sonderbedingungen" reduzieren kann. Ich denke, heutzutage bekommt man Dijkstras und Knuths Beispiele auch elegant ohne goto hin, wenn man break , continue und return benutzen darf.

Gruß,
SP

Simon2

int z;
std::cout << "Bitte geben Sie eine Zahl zwischen 1 und 10 ein:";
std::cin >> z;
while (z < 1 || z > 10) {
  std::cout << "Die Zahl " << z << " ist nicht zwischen 1 und 10.\nBitte geben Sie eine Zahl zwischen 1 und 10 ein:";
  std::cin >> z;
}

Ginge auch - da hätte man allerdings Ausgabe/Eingabe doppelt. Andererseits ist hier eine klare "Fehlerfallbehandlung" separat gekapselt, was IMHO auch Vorteile hat.

Gruß,

Simon2.

Um ehrlich zu sein, das würde ich so schreiben:

int z;
for (;;) {
  std::cout << "Bitte geben Sie eine Zahl zwischen 1 und 10 ein:";
  std::cin >> z;
  if (1 <= z && z <= 10) break;
  std::cout << "Die Zahl " << z << " ist nicht zwischen 1 und 10.\n";
}

Das ist ein typischer Kandidat für die "and-a-half"-Schleifen, bei denen die Abbruchbedingung weder am Anfang noch am Ende steht.

Gruß,
SP

freakC++

Hallo,
bei mir wird gar nicht mehr C++ unterrichtet. Ich lerne Delphi in der Schule aber da meine "Hauptsprache" nun mal
C++ ist unterhalte ich mich mit meinem Lehrer schon mal darüber! Als ich ihm ein kleines Programm gezeigt habe, meinte er halt, dass
break und continue schlechter Stil wäre und dass man sie meiden solle...

Ich war damals noch nicht so erfahren und habe einfach gesagt "Ich weiß!" doch darüber schäme ich mich, denn
ich sagte es nur aus Unwissenheit bzw und meinen Lehrer zufrieden zu stellen!

Heute würde mir das nicht mehr passieren, da ich der Meinung bin, dass break und continue durchaus angebracht sind!

Vielen Dank
lg, freakC++

drakon

Es kommt halt immer auf die Situation an. Auch ein goto hat seine Berechtigung. Wenn man allerdings goto , oder auch break und continue ständig braucht lediglich, weil man zu faul ist sich, wie schon vorhin gezeigt, gedanken über Bedingungen o.ä. zu machen, dann ist das bestimmt schlechter Stil.
Wen man allerdings einen Grund hat und Alternativen zu umständlich/unleserlich wären, dann kann man alles brauchen, was die Sprache hergibt.

JustAnotherNoob

Ich stelle fest, dass Gegner von break und continue in diesem Thread keine Argumente bringen

Vollkommen richtig, ich dachte die Argumente wären allen bekannt

Wie auch immer break, continue und return sind ebenso Sprunganweisungen wie goto, es gilt die selbe Argumentation...
Man kann also nur diskutieren ob die Probleme, die durch Sprunganweisungen verursacht werden nicht geringer sind als die, die durch die umstrukturierung verursacht werden, deswegen gibt es nur Beispiele, wie man es besser machen kann.

deswegen =>

Als ich ihm ein kleines Programm gezeigt habe, meinte er halt, dass
break und continue schlechter Stil wäre und dass man sie meiden solle...

So formuliert imho richtig. Meiden heißt aber auch nicht, gar nicht verwenden. Wer weiß was du ihm vorgelegt hast