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++

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.

lg, freakC++

Einige Probleme lassen sich mit Endlosschleifen eleganter und besser lesbar lösen.

Welche?

Aber wenn es angebracht ist, darfst du break ruhig 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!

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).

Es ist schon so, dass man goto nicht sehr oft braucht/brauchen sollte, aber wenn es wirklich sinnvoll ist und man die Alternativen gecheckt hat und goto die 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.

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.

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.

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

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

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.

guten morgen && lg lolo

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

lg lolo

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++

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ückgeben

Das ist also einfach nur verboten! Also nix Geschmackssache oder Stilverbesserung.

lg, freakC++

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.

Einmal sagt es der Compiler...

Wenn du mit Compiler den Typen meinst, dem du deinen Quelltext zum Übersetzen gibst, würde ich mir einen anderen suchen. Der soll keinen Kommentar abgeben sondern seine Arbeit erledigen.
Wenn du selber ein soclhes Programm bedienst (z.B. GCC), dann handelt es sich wohl um eine falsche Anwendung, sprich einen tatsächlichen Programmierfehler.
Auf nicht initialisierte Pointer zugreifen ist ja auch böse böse böse, nur - der Compiler meldet das nicht!

Ich danke euch allen.
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.

Dito.

Ich verwende break & continue zwar selten, aber durchaus wenn es der Übersichtlichkeit förderlich ist.

Fellhuhn schrieb:

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.

Es sei den man setzt ohnehin weitgehend auf Stackvariablen in Schleifen, oder RAII-Mechanismen.

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.

Nein, so kann man nicht argumentieren. Es gibt z.B. das Schlüsselwort auto , das völlig überflüssig ist (und in C++0x umgewidmet wird, weil es nie jemand benutzt). Auch von zweifelhaftem Wert ist register . Und in portablen Programmen kann nie das Schlüsselwort asm vorkommen.
Die Funktionen setjmp / longjmp sollte man auch nicht verwenden. Na und so weiter ... die Sprache enthält vieles nur aus historischen Gründen, sie macht auf keinen Fall Stilvorgaben.

lg, freakC++