Aber nun an euch?
Ich hab in der schule (htl) von den lehrern immer gehört schleifen soll man nicht breaken und mit bestimmten conditions und abfragen versehen damit unerwünschtes nicht ausgeführt wird...
sprich...war nicht gern gesehen..bei keinem

ich hab mir das damals angewöhnt und nicht mehr drüber nachgedacht...(also nicht breaken)

Was meint ihr? ist das ne anfängereinstellung die man einfach ned verliert oder es ist eh egal bzw. gibts gründe warum mans (nicht) tun sollte?

Kuldren schrieb:

Ich hab heut mit meinem Tutor geredet und gefragt obs ok ist wenn man mit break; aus ner (for)schleife rausgeht...
er meinte man sollte (im pseudocode) eher schreiben "verlasse schleife" oder "retourniere wert"...

Komische Antwort auf deine Frage

Kuldren schrieb:

Ich hab in der schule (htl) von den lehrern immer gehört schleifen soll man nicht breaken

Stimme ich nicht zu. Mir fallen keine Gründe ein, wieso man eine Schleife, die nichts mehr zu tun hat, nicht mit break beenden sollte, sodass sie nicht unnütz weiterläuft.

Höre ich auch zum ersten Mal sowas ...

Hi,

Kuldren schrieb:

Ich hab heut mit meinem Tutor geredet und gefragt obs ok ist wenn man mit break; aus ner (for)schleife rausgeht...
er meinte man sollte (im pseudocode) eher schreiben "verlasse schleife" oder "retourniere wert"...

Komische Antwort auf deine Frage

Kuldren schrieb:

Ich hab in der schule (htl) von den lehrern immer gehört schleifen soll man nicht breaken

Stimme ich nicht zu. Mir fallen keine Gründe ein, wieso man eine Schleife, die nichts mehr zu tun hat, nicht mit break beenden sollte, sodass sie nicht unnütz weiterläuft.

Höre ich auch zum ersten Mal sowas ...

mein info lehrer hat mir auch sowas gesagt, er meinte, dass die funktionen dann nicht mehr mathematisch validierbar sind *schulterzuck*

eine Schleife, die nichts mehr zu tun hat

Huch ?!? Wie kann denn sowas passieren ?

Im Prinzip meinen die Info-Lehrer genau das mit "nicht mehr mathematisch validierbar".

Man kann also nicht voraussagen, wie lange eine Schleife läuft (was heisst, dass die Laufbedingung der letzte Mist ist).

std::string strPW("Knautsch");
std::string strCmd;
bool ok = false;
for(unsigned int i = 1; i<=5; ++i)
{
    std::cout << "Versuch: " << i << std::endl;
    std::cin >> strCmd;
    if(strCmd == strPW)
    {
        std::cout << "Danke" << std::endl << std::endl;
        ok = true;
        break;
    }
    else
        std::cout << "Falsch" << std::endl << std::endl;
}

// something code

(ok) ? DoSomeThing() : ErrorWrongPW();

Was meint ihr? ist das ne anfängereinstellung die man einfach ned verliert oder es ist eh egal bzw. gibts gründe warum mans (nicht) tun sollte?

ich glaube selbst der naivste anfänger würde nicht auf so einen mist kommen.;)
natürlich darf man aus schleifen hinaushüpfen, aus einer schleife mit 'return' die funktion verlassen, goto benutzen usw...
und wieso soll das nicht 'mathematisch validierbar' sein?

es ist doch sogar manchmal besser aus der schleife rauszuspringen. das macht ja in manchen fällen das programm schneller. stellt euch vor ihr hättet eine shleife die 100000000 durchlaufen soll, aber nach 2 durchläufen schon das erreicht hat was es soll, warum sollte sie weiterlaufen.

gruss
msp

for(;;)
{
    if(MouseMove() == true)
        break;
    ShowBildschirmSchoner();
}

wie kannst du den bildschirmschoner beenden ohne break oder return?

an dieser stelle kann man zwar auch eine while machen - dient aber nur zur veranschaulichung

oder angenommen du hast eine schleife wo eine komplexe berechnung angestellt wird - diese berechnung dauert immer so 5 min

for(unsigned int i = 0; i<200000; ++i)
{
    if(DoBerechnung() == true) // eine berechnung dauert 5 min
        break;
}

soll nun jedesmal weiterhin die berechnung laufen obwohl das ergebnis fest steht?
und dann pro durchlauf 5 min?
und abgesehen davon das die berechnung evtl daten veraendern kann die nach erfolgreicher beendung gar nicht mehr geaendert werden duerfen/sollen?

Ich finde das es immer besser ist eine Schleife bis zum ende laufen zu lassen. DIe Rechner werden ja immer schneller. Macht ja nichts wenn das Programm dann langsamer wird weil man eine Schleife nicht bereits beendet obwohl das erreicht wurde was man wollte.

Dann lass mal in der Schleife 100000000 mal irgendwelche Berechnungen ausführen obwohl das Ergebnis eigentlich schon nach 2 Durchläufen feststeht. Und dann schau mal ob es dir nicht evtl. doch zu lange dauert.

Warum sollte das mathematisch nicht validierbar sein? Es ist doch vorhersehbar welche Werte die Schleife zum vorzeitigen Abbruch führen.

Was sagt(e) dein Lehrer denn zu continue?

user schrieb:

Ich finde das es immer besser ist eine Schleife bis zum ende laufen zu lassen. DIe Rechner werden ja immer schneller. Macht ja nichts wenn das Programm dann langsamer wird weil man eine Schleife nicht bereits beendet obwohl das erreicht wurde was man wollte.

Dann lass mal in der Schleife 100000000 mal irgendwelche Berechnungen ausführen obwohl das Ergebnis eigentlich schon nach 2 Durchläufen feststeht. Und dann schau mal ob es dir nicht evtl. doch zu lange dauert.

Schon mal was von Zynismus gehört?

was machst du dann damit?

for(;;)
{
    if(MouseMove() == true)
        break;
    ShowBildschirmSchoner();
}

wie kannst du den bildschirmschoner beenden ohne break oder return?

while(!MouseMove()) {
    ShowBildschirmSchoner();
}

Mr Evil schrieb:

for(unsigned int i = 0; i<200000; ++i)
{
    if(DoBerechnung() == true) // eine berechnung dauert 5 min
        break;
}

soll nun jedesmal weiterhin die berechnung laufen obwohl das ergebnis fest steht?
und dann pro durchlauf 5 min?

unsigned int i = 0;
while(i < 200000 && !DoBerechnung()) {
   i++
}

aber natürlich spricht nichts gegen ein break in schleifen wenns angebracht ist.

Schon mal was von Zynismus gehört?

Ja, aber

user schrieb:

Ich finde das es immer besser ist eine Schleife bis zum ende laufen zu lassen.

hört sich für mich nicht nach Zynismus an. Und wenn du dich gleich angegriffen fühlst, dann ist das nicht mein Problem.

stellt euch vor ihr hättet eine shleife die 100000000 durchlaufen soll

Da war sein Argument die Schleifenbedingung eben so aufzubauen dass sie ggf. erfüllt bzw. unerfüllt ist und die schleife beendet...

@Marc++us:

??

Ja hat mich nur interessiert...hat damals sogar auch Punkte bei Tests gekostet wenn wir das so verwendet haben glaub ich...
Aber jetz an der Uni bin ich eben manchmal überrascht was da von einigen gesagt wird (bzw. es gibt natürlich auch da leute die oft was anderes sagen aber meistens stimmen sie überein... aber bei diesem Thema... )

Kuldren schrieb:

Ich hab in der schule (htl) von den lehrern immer gehört schleifen soll man nicht breaken

Stimme ich nicht zu. Mir fallen keine Gründe ein, wieso man eine Schleife, die nichts mehr zu tun hat, nicht mit break beenden sollte, sodass sie nicht unnütz weiterläuft.

Aber das stellt doch die Abbruchbedingung schon sicher. Wofuer also ein break?

Aber das stellt doch die Abbruchbedingung schon sicher. Wofuer also ein break?

Was machste mit einem

while(irgendeine Bedingung)
{
  if(erste Operation erfolgreich) break;
  zweite Operation
}

Wir das Programm wirklich besser, wenn ich dafür ne extra bool-variable einführe, die ich auf true setze wenn ich fertig bin und die dann in der Bedingung mit drinsteht? -- Ich finde nicht.

...
Was machste mit einem

while(irgendeine Bedingung)
{
  if(erste Operation erfolgreich) break;
  zweite Operation
}

...

while(irgendeine Bedingung && !(erste Operation erfolgreich))
   zweite Operation

Wieso nicht ?

Ich persönlich bevorzuge klare Abbruchbedingungen, weil man dann sofort "im Schleifenkopf" sehen kann, wann sie abbricht.

Aber ich bin kein prinzipieller Gegener von break (oder return, throw, ...); sehr verschachtelte Bedingungen können mit break&Co lesbarer gemacht werden, aber bei "langen Schleifenkörpern" kann die Übersichtlichkeit auch darunter leiden.

Gruß,

Simon2.

meistens kam das argument...auch hier würds funktionieren:
dass man mit den bedingungen( boolsche oder was auch immer für variablen)
ein break umgehen kann:

while(irgendeine Bedingung)
{
  if(erste Operation erfolgreich) irgendeine bedingung=false;
  else  
  zweite Operation
}

bzw. kann man ja mehrere argumente in die bedingung einbauen und mit UND bzw. ODER verknüpfen...

Ich wollte lediglich wissen ob es (technische) gründegibt break nicth zu benutzen
war ein argument der lehrer und ich verstehe nicht welch technische gründe das haben könnte...

while(irgendeine Bedingung && !(erste Operation erfolgreich))
   zweite Operation

Wieso nicht ?

Mach bitte aus erste Operation was zwei- oder dreizeiliges.

Was machste mit einem

while(irgendeine Bedingung)
{
  if(erste Operation erfolgreich) break;
  zweite Operation
}

Es gibt keinen Zusammenhang zwischen "irgendeine Bedingung" und "erste Operation". Aber beide beenden die Schleife. Was soll sowas ?

Jester schrieb:

Was machste mit einem

while(irgendeine Bedingung)
{
  if(erste Operation erfolgreich) break;
  zweite Operation
}

Es gibt keinen Zusammenhang zwischen "irgendeine Bedingung" und "erste Operation". Aber beide beenden die Schleife. Was soll sowas ?

Sowas schreibt man meistens wenn "irgendeine Bedingung" keine Seiteneffekte hat, "erste Operation" aber schon. In dem Fall halte ich es so wie es oben steht auch für wesentlich klarer als wenn beides im Schleifenkopf steht.

Sich auf die Kurzschlusslogik zu verlassen damit bestimmte Teile eines Ausdrucks mit boolschen Operatoren in einer Schleifenbedingung nichtmehr ausgeführt werden halte ich für Mist, vor allem wenn diese Teile eben Seiteneffekte haben.
Pfui Pfui Pfui.

@OP: nein, technische Gründe gibt es nicht.