Endlosschleife --> was sagt ihr (Mein Informatiklehrer sagt wieder, dass...)
-
Hallo zusammen,
ich habe vor längerer Zeit hier mal einen Thread eröffnet, in welchem ich euch gefragt habe, ob "break" eine anerkannte Art der Progrmmierung ist (Mein Informatiklehrer sagt, dass...). In manchen Fällen wie bei switch ist dieses Schlüsselwort natürlich absolut notwendig. Hier geht es aber darum, ob ich "break" auch zum Beenden von Schleifen benutzen darf. Mir wurde in einer Klausur letztens wieder angemerkt, dass ich doch bitte Abstand von diesem bösen Wort halten solle. Da ich das jedoch nicht finde, habe ich meinen Lehrer mal gefragt, was denn eine moderne Alternative sei. Er sagte, man solle das mit einer Endlosschleife lösen, bei der beispielsweise eine bool Variable den anderen Wert annimmt, sobald ich "break" setzen würde. Dann wäre die Schleife auch sofort beendet.Ich persönlich mag Endlosschleifen nicht sehr, da sie zum einen die CPU sehr auslasten und zum anderen für mich kein sauberer Stil sind (manchmal nutze ich sie auch).
Ich wollte mal fragen, ob ihr auf der Seite der Endlosschleife oder auf der Seite von "break" steht.
Vielen Dank
lg, freakC++
-
Versteh ich nicht, wo ist bei dir der Unterschied zwischen einer Endlosschleife und einer Endlosschleife? Ist die Schleife, die du mit break verlassen willst, denn keine?
Einige Probleme lassen sich mit Endlosschleifen eleganter und besser lesbar lösen.
Und eine Schleife mithilfe eines Flags anstatt break zu verlassen, ist fehleranfällig (da eben die Schleife nicht unbedingt sofort verlassen wird) und ziemlich sinnfrei, wobei Ausnahmen die Regel bestätigen mögen.
-
Die Schleife, die ich verlassen möchte, ist keine Endlosschleife. Man solle also eine umarmende Endlosschleife machen, die abgebrochen wird, wenn man "break" setzen würde.
lg, freakC++
-
Athar schrieb:
Einige Probleme lassen sich mit Endlosschleifen eleganter und besser lesbar lösen.
Welche?
-
So eine Pauschalisierung ist Unsinn.
Lass mich raten. Dein Lehrer ist irgendwas um die 60 und programmiert selbst eher C, als C++, weil er das halt mal so gelernt hat. Und genau damals auch die strukturierte Programmierung gelernt hat und seit dort nichts dazu gelernt hat.
Du kannst ja mal nachfragen was an seiner "modernen" Methode so viel besser ist, als ein break. Nimmt mich Wunder, was er da antwortet..Aber wenn es angebracht ist, darfst du
breakruhig benutzen. Aber wenn du bessere Noten bekommst, wenn dus so machst, wie er will, dann machs halt, aber vergiss nicht, dass jedes Sprachmittel eingesetzt (mit der richtigen Begründung) werden darf und dann völlig legitim ist.Mitdenken ist erwünscht!
-
Kóyaánasqatsi schrieb:
Athar schrieb:
Einige Probleme lassen sich mit Endlosschleifen eleganter und besser lesbar lösen.
Welche?
Das kann man schlecht pauschal sagen, aber es kommt immer wieder vor, dass ich eine Endlosschleife bevorzuge. Meist immer dann, wenn die Abbruchbedingung etwas komplexer wird. Anstatt break kann das natürlich auch return sein.
Vielleicht beim Lesen von Datensätzen aus einer Datei, bis zu einem Punkt, wo eine Reihe von Bedingungen zutreffen oder ein Fehler auftritt (wobei bei Fehlern natürlich auch Exceptions eingesetzt werden könnnen).
-
Ich verweise gern auf meinen kürzlich erstellten Thread, wo es um eine ähnliche Problematik ging, nämlich um Sprungmarken, die man benutzen kann, um aus Schleifen vorzeitig rauszuhüpfen. Ganz ähnlich deinem Break. Ich kann das nachvollziehen, dass du es nicht verstehst wenn dein Lehrer sagt, dass das break böse sei. Ich versteh solche eine Haltung bei meinen Profs auch nicht. Schon wenn break, continue oder goto sagst, geht die Stimme von denen paar Dezibel nach oben. Und dann machen sie einen Zinober, dass du da jetzt als armer Schüler/Student denkst, du hättest was weiß ich verbrochen.
Wie dir schon geraten wurde, machs in den Klausuren lieber so wie es dein Herr Lehrer hören will, und privat kannst du die "ungeliebten" Befehle nehmen. Das ist meine Meinung, auch wenn ich dafür oft und gerne Spott ernte.
-
Viele übertreiben es halt einfach mit den Ermahnungen.
Es ist schon so, dass man
gotonicht sehr oft braucht/brauchen sollte, aber wenn es wirklich sinnvoll ist und man die Alternativen gecheckt hat undgotodie elegantere Variante ist, dann soll man es auch nehmen.Was halt bei vielen das Problem ist, die ihre "böse" Sachen Theorien vertreten, dass sie halt nicht auch gleich erklären, WARUM die Sachen böse sind. Dann hat auch kein Student die Chance in den Fällen, wo es wirklich Sinn macht die böse Seite zu benutzen es zu wissen.
-
freakC++ schrieb:
Er sagte, man solle das mit einer Endlosschleife lösen, bei der beispielsweise eine bool Variable den anderen Wert annimmt, sobald ich "break" setzen würde. Dann wäre die Schleife auch sofort beendet.
Dann wärs ja keine Endlosschleife mehr. Wovon redest du da überhaupt? Es klingt eher danach, als hättest du eine Schleife mit der Schleifenbedingung true, die durch break verlassen wird, und solltest sie so umformulieren, dass sie im Schleifenkopf abgebrochen wird:
while (true) { A; if (foo) break; B; }; // ==> bool b = false; while (!b) { A; if (foo) b = true; else B };Richtig? Also mal abgesehen davon, dass das beides keine Endlosschleifen im eigentlichen Sinne des Wortes sind, so ist doch eher die erste als solche zu bezeichnen, weil sie formal keine Schleifenbedingung hat. Naja sei's drum. Mir wär wohler, du würdest die Dinger als Tischbeine bezeichnen, da Endlosschleife schon für Schleifen, die kein Ende haben, belegt ist.
Ich persönlich mag Endlosschleifen nicht sehr, da sie zum einen die CPU sehr auslasten und zum anderen für mich kein sauberer Stil sind (manchmal nutze ich sie auch).
Woher soll denn die CPU wissen, ob das eine Endlosschleife ist? Die lastet die CPU genauso aus wie jede andere Schleife.
Und ob das sauberer Stil ist für dich ist erstmal egal, es sei denn, du kannst deinen Lehrer davon überzeugen, dass dein Stilempfinden wichtiger ist als seins.Ich wollte mal fragen, ob ihr auf der Seite der Endlosschleife oder auf der Seite von "break" steht.
Ich habe es oft, dass die erste Version einer Schleife ein break hat, dass ich sie dann aber irgendwann so umformuliere, dass die Schleifenbedingung auf natürliche Art und Weise im Schleifenkopf zu liegen kommt.
Wenn man zusätzliche boolesche Flags einführen muss verkompliziert sich der Kontrollfluss, davon halte ich nichts.
-
Also mir kommt eine Problem in den Sinn, den wir mal in einem Informatikunterricht in der Schule hatten. Die Aufgabe war einfach: Man soll eine Eingabe anfordern und prüfen und nur dann akzeptieren, wenn sie ok ist. Ansonsten Fehler ausgeben und halt nochmal anfordern. Klingt einfach. Jetzt machen wir das mal mit der reinen Lehre mit einer Schleife mit einer Abbruchbedingung entweder am Anfang oder am Ende:
do { std::cout << "Bitte geben Sie eine Zahl zwischen 0 und 9 ein:"; std::cin >> zahl; if (zahl < 0 || zahl > 9) std::cout << "fehlerhafte Eingabe"; } while (zahl < 0 || zahl > 9);Sehr unschön, da doppelte Prüfung. Besser mit einer Bool-Variablen:
bool ok = false; while (!ok) { std::cout << "Bitte geben Sie eine Zahl zwischen 0 und 9 ein:"; std::cin >> zahl; if (zahl < 0 || zahl > 9) std::cout << "fehlerhafte Eingabe"; else ok = true; }Besser. Aber eine unnötige Variable in einem Scope, der nichts mit der eigentlichen Schleife zu tun hat. Und so eine bool-Variable ist oft Ausdruck einer falschen Schleifenwahl oder sonstigen verknoteten Abläufen. Na ja - so schön ist das nicht.
Und jetzt mit break:while (true) { std::cout << "Bitte geben Sie eine Zahl zwischen 0 und 9 ein:"; std::cin >> zahl; if (zahl >= 0 && zahl <= 9) break; std::cout << "fehlerhafte Eingabe"; }Finde ich persönlich am schönsten. Kurz und übersichtlich, leicht verständlich, keine überflüssige Variable und eine einfache Abbruchbedingung. Zwar in der Mitte, aber genau das ergibt sich aus der Aufgabenstellung.
Jetzt viele Jahre später bin ich noch immer der Überzeugung, dass ein break in vielen Situationen die beste Lösung ist. Auch in meinen Programmen kommt das hin und wieder vor.
-
[quote="tntnet"]
do { std::cout << "Bitte geben Sie eine Zahl zwischen 0 und 9 ein:"; std::cin >> zahl; if (zahl < 0 || zahl > 9) std::cout << "fehlerhafte Eingabe"; } while (zahl < 0 || zahl > 9);da brauchen wir uns nicht drüber unterhalten...
bool ok = true; do{ std::cout << "Bitte geben Sie eine Zahl zwischen 0 und 9 ein:"; std::cin >> zahl; if (zahl < 0 || zahl > 9) std::cout << "fehlerhafte Eingabe"; else ok = false; }while(ok);denke hier wird schon deutlich das es komplizierter als eigentlich nötig war sonst hättest es doch gleich so gemacht;)
do{ std::cout << "Bitte geben Sie eine Zahl zwischen 0 und 9 ein:"; std::cin >> zahl; if (zahl >= 0 && zahl <= 9) break; std::cout << "fehlerhafte Eingabe"; }while(1);wir wollen ja fair bleiben

lg lolo
-
ich bilde mir ein mal gehört zu haben, dass das was am ehesten eintrifft in den ersten block soll und das andere in den else block da es dann schneller ausgeführt werden kann, also
if(){ //eher oft }else{ //eher selten }und wenn man jetzt davon ausgeht das es stimmt und der ein oder andere user in der lage ist das zu machen was man ihm sagt, ist ein
if(true) break;schneller als
if(false) ... else break;lg lolo
-
Was spricht gegen
for( bool exit=false; !exit; ) { std::cout << "Bitte geben Sie eine Zahl zwischen 0 und 9 ein:"; std::cin >> zahl; if (zahl < 0 || zahl > 9) std::cout << "fehlerhafte Eingabe"; else exit = true; }Für alle break-Hasser. Das Exit-Flag ist nur in der Schleife sichtbar. Wenn die durch ist gibt es die Variable nicht mehr.
Mir gefällt hier allerdings die Variante mit dem break auch besser.
-
schade das ich mich ins c++ forum verirrt habe, sonst könnt ich sagen, for(int x... gibts in c89 nicht :p
guten morgen && lg lolo
-
aber da ist das break oder die flag auch nciht unbedingt notwendig:
template <typename T> T get(std::istream &in, std::ostream &out) { T ret_val; while (! (in >> ret_val) ) { out << "falsch usw."; clear_stream(in); }; clear_stream(in); return ret_val; } template <typename T> T get(std::istream &in, std::ostream &out, const T& lower_bound, const T& upper_bound) { T ret_val = get<T>(in, out); while( (ret_val < lower_bound) || (ret_val > upper_bound) ) { out << "außerhalb der grenzen..."; clear_stream(in); ret_val = get<T>(in, out); }; return ret_val; }und die eine zeile, die ich da doppelt drin habe, kann man imho so und so nur mit verrenkungen vermeiden...
bb
-
kpl. od das jetzt an den templates liegt aber so mit einem blick check ich nicht was du da machst

lg lolo
-
Dann verteufelt er vermutlich auch continue in Schleifen...
-
Hallo,
ich meite eigentlich sowas wie Bashar es in seimem zweiten Beispiel hat. Vielleicht war meine Ausdrucksweise falsch. Strenggenommen ist es keine Endlosschleife...naja, ihr habt mich dennoch verstanden!Kann man sagen, dass eigntlich alle Schlüsselwörter aus C++ zu nutzen sind? Andernfalls könnte man argumentieren, dass es solche sonst ja nicht geben würde. Naja, trotzdem gibt es ja immer wieder "Stilverbesserungen". Heute würde ja auch keiner mehr das schreiben:
void main() { cout << "Hello World" << endl; }lg, freakC++
-
freakC++ schrieb:
Naja, trotzdem gibt es ja immer wieder "Stilverbesserungen". Heute würde ja auch keiner mehr das schreiben:
void main() { cout << "Hello World" << endl; }Das liegt aber nicht daran dass es als nicht schön erachtet wird!
g++ main.cpp -o main main.cpp:4: Fehler: »::main« muss »int« zurückgebenDas ist also einfach nur verboten! Also nix Geschmackssache oder Stilverbesserung.
-
Mmmhh...da haste recht, aber die Nutzung von break, continue wird mir genauso als verboten dargestellt. Einmal sagt es der Compiler...einmal der Lehrer

lg, freakC++
-
Ich verwende immer break & continue wenn es Sinn macht. So einfach ist das.
Die Verwendung von irgendwelchen Abbruchvariablen die in langen Schleifen verwendet werden, führen meist zu viel unübersichtlicheren Verschachtelungen.Was man bei dem ganzen break/continue/return-Gedönse mitten im Code natürlich berückstigen muss ist das freigeben eventuell angeforderten Speichers. Da kann es sonst schnell zu Problemen führen.