for(;;) schleife verlassen

junix

Ausserdem ist for(;;) in mehrerlei Hinsicht schlecht:

a) Wenn man sowieso keine Initialisierung und keine Aktion am Ende der Schleife benötigt, kann man ebensogut while() nehmen.
b) Man sollte so oder so eine Abbruchbedingung definieren, damit man "aufhänger" vermeiden kann.

In deinem Fall wäre dies zum Beispiel ein "Terminate"-Flag, mit dem du das Programmende markieren kannst und so die Schleife automatisch abbricht...

-junix

aber nimm lieber while für solche Schleifen.

Coda

so
if(pauswahl==1)
return;
else
break;

Der bricht nur ab ... wiederholen tut er aber nicht

genauso das
if(pauswahl==1)
return;

Daniel E.

junix schrieb:

Ausserdem ist for(;;) in mehrerlei Hinsicht schlecht:

a) Wenn man sowieso keine Initialisierung und keine Aktion am Ende der Schleife benötigt, kann man ebensogut while() nehmen.

Verstehe ich nicht. Was ist an einem while mit konstanter Schleifenbedingung besser? Endlosschleifen sind die einzigen Situationen, wo ich erntshaft for in Betracht ziehen würde. Sonst halte ich dieses Sprachkonstrukt für unzumutbar. YMMV.

Coda

mh... muss ich nen zeiger machen ?
weil
while(pauswahl=1)
aber pauswahl ist in der while schleife....
muss ich nun in heap ablegen ?

so verläßt du nur deine Schleife

if(pauswahl==1) 
break;

und so deine Funktion:

if(pauswahl==1) 
return;

volkard

junix schrieb:

Ausserdem ist for(;;) in mehrerlei Hinsicht schlecht:
a) Wenn man sowieso keine Initialisierung und keine Aktion am Ende der Schleife benötigt, kann man ebensogut while() nehmen.
b) Man sollte so oder so eine Abbruchbedingung definieren, damit man "aufhänger" vermeiden kann.
In deinem Fall wäre dies zum Beispiel ein "Terminate"-Flag, mit dem du das Programmende markieren kannst und so die Schleife automatisch abbricht...
-junix

trenn dich mal von pascal und lern programmieren.
a) pascaller sagen while(true) und c++-er distanzieren sich von denen, indem sie sagen, daß sie mit ihrem for sogar umgehen können. for(;;) ist ein markanteres idiom für endlosschleife.
b) als pascaller solltest du endlosschleifen vermeiden. tu es meinetwegen, aber empfiehl nix dogmatisches mehr aus der strukturierten programmierung.
und auf keinen fall ein künstliches terminate-flag, das sowohl lahm als auch komplex macht.

DrGreenthumb

Was ist denn bitte an for(;;) mehr markantes Idiom für Endlosschleife als while(1) ?
Letzteres empfinde ich rein sprachlich als viel logischer.

PAD

Neben der for oder while Philosopie, verstehe ich noch nicht was Coda will

Zu einem will er bei 1 das Proggi verlassen, bei 2 wiederholen, aber erst nach dem das switch durch ist.

Das ist irgendwie wiedersprüchlich.

Sein BeispielCode bietet 5 Fälle default mit break an, d.h wenn eingabe irgend eine Zahl ist wird genau ein case ausgeführt und das Switch ist durch. somit ist die Lsung mit return in case 1 correct.

Oder stehe ich auf der Leitung?

volkard

DrGreenthumb schrieb:

Was ist denn bitte an for(;;) mehr markantes Idiom für Endlosschleife als while(1) ?
Letzteres empfinde ich rein sprachlich als viel logischer.

for verwendet man entweder komplett mit initialisierung, bedingung und weiterschaltung oder ganz leer. da sieht man das ganz leere und erkennt es auf einen blick ganz leicht und ohne zu überlegen und es ist das bild für endlosschleife.
while hingegen hat irgendeine bedingung drin, am besten ohne logische operatoren, machmal sogar nur eine variable. der unterschied zwischen while(p) und while(1) kommt nicht so rüber wie der unterschied zwischen for(int i=0;i<10;++i) und for(;;).

Coda

PAD
ich habe eine auswahl ... (switch und davor ne schleife)
ich will das man nach dem durchlauf fragt ob man das programm verlassen soll oder nicht.
und wenn man nicht auswählt soll der zu dem switch wieder springen. Bei verlassen anklicken soll der das ganze programm verlassen.

PAD

Suchst du so eine Lösung??

....
for(;;)
{
  /// Get Eingabe Zahl
  switch(eingabe)
    {
    case 1: break; // dieses break beendet das Switch da innerhalb des Switch 
    ......
    default:
    break;
    }
 // get Eingabe Y/N Schreib dir eine Eingabe Funktion die die 'Y' oder 'N' zurückliefert
 if ('Y'==Eingabe)
    break; // Dieses break beendet die for Schleife da innerhalb des for aber auzßerhalb des switch
}

...

Wenns das ist, schau dir in einer Referenz noch mal die Wirkung von break; continue; an

The C break Statement
The break statement terminates the execution of the nearest enclosing do, for, switch, or while statement in which it appears. Control passes to the statement that follows the terminated statement.

The C continue Statement
The continue statement passes control to the next iteration of the do, for, or while statement in which it appears, bypassing any remaining statements in the do, for, or while statement body. A typical use of the continue statement is to return to the start of a loop from within a deeply nested loop.

Wer will kann anstelle des for( ; ; ) genauso while(1) schreiben,
Wers unbedingt aus irgendwelchen philosophishen Gründen will kann auch schreiben do { }while(1),
Wer weder for noch while sehen will für den hät ich #define forever for ( ; ; ) oder #define forever while(1).
Hier noch eine spezielle Lösung, eignet sich für jede Vorlesung

HFO: // Kurzform für Hell freezes over
....
//Anstelle des break; muss hier dann
goto EndOfWork;
....
goto HFO;
EndOfWork:
.....

Mir ist es wurst, je nach Tagesform nehme ich for( ; ; ) oder while(1).
Aus Forums sicht ist while(1) besser denn wenn man for ( ; ; ) ohne Blanks Schreibt kommt das for(;;) raus

Hat sich schon einer mal den Assembler-Output angeschaut, ich nicht?

junix

@Daniel E.: Gut, zugegeben, ob nun while(true) oder for(;;) ist relativ irelevant.

volkard schrieb:

b) als pascaller solltest du endlosschleifen vermeiden.

Bin zwar kein Pascaller aber trotzdem finde ich endlosschleifen gefährlich. Wozu bitte in eine Schleife eine if für den todsicheren Ausstieg klatschen, wenn dir das Schleifenkonstrukt diese Möglichkeit freihaus liefert? Ist schon rein Wart- und Lesbarkeitstechnisch schwachsinn... denn dann muss ich immer innerhalb der Endlosschleife nach der über allem stehenden Abbruchbedingung suchen... Arbeit die ich mir doch eigentlich sparen könnte?

volkard schrieb:

und auf keinen fall ein künstliches terminate-flag,[...]

...wer sagt etwas von künstlich? Hier wäre das Terminate-Flag sogar sinnvoll... Beim Beenden des Programms wird das Flag gesetzt, die Schleife springt raus und nach dem Superloop des Programms können, statt beim Return direkt aus dem Programm zu springen, dann noch Aufräumarbeiten erledigt werden...

volkard schrieb:

[...]das sowohl lahm als auch komplex macht.

Ich bin auch für sparsames Programmieren und Haushalten mit Speicher und Prozessorzeit aber die Taktspalterei wird heute nicht mal mehr in der embedded-Programmierung betrieben. Und inwieweit die Komplexität hier in die höhe getrieben würde mit einem beenden-flag, kann ich nicht nachvollziehen...

-junix

PAD

Gerade bei Systemen die "endlos" laufen, ist es IMHO oftmals besser eine expliziete Terminierung innerhalb der Schleife einzubauen als sie in der Endlosloop als Condition zu verstecken. Die Terminierung wird dadurch für mich im Code optisch deutlicher. Die minimale Bestrafung durch Speicher und Taktverbrauch nehme ich da gerne in Kauf.

Aber letztendlich ist das noch nicht mal eine Philosophiefrage sondern eher eine Geschmacksfrage und über Geschmack kann man bekanntlich nicht streiten.

volkard

junix schrieb:

...wer sagt etwas von künstlich? Hier wäre das Terminate-Flag sogar sinnvoll... Beim Beenden des Programms wird das Flag gesetzt, die Schleife springt raus und nach dem Superloop des Programms können, statt beim Return direkt aus dem Programm zu springen, dann noch Aufräumarbeiten erledigt werden...

aufräumen tut der destruktor! die ist nicht pascal.
ich weiß bereits, wie nutzlos gespräche mit leuten sind, die sich vom "strukturierten programmieren" auf gedeih und verderb nicht lossagen können. ich sage es auch nicht für dich, sondern um ein paar der mitlesenden nubes die chance zu geben, mal ne gegenmeinung gehört zu haben.
und deine argumente sind mällig, wenn ich mal schau, daß du einerseits von nem while mit ner todsicheren bedingung sprichst und so tust, als sei das sicher und andererseits genau diese bedingung nur dein künstiches flag abfragt. ob ich nun in der schleife vergesse rauszuspringen oder ob ich vergesse, das künstliche flag zu setzen, ist doch völlig banane. beide wege sind fast genauso unsicher. eher ist die version ohne flag dadurch leicht sicherer, daß der code eine um-die-ecke-denkerei weniger hat (nämlich die, daß man zu beenden nicht return;! oder goto ende;! sagt, sondern finisched=true;(irgendwer wird schon beenden, wenn ich das setze, vielleicht)).

werde auf argumente von dir in diesem thread nicht mehr eingehen. hab gesagt, was gesagt werden mußte.

PAD

:p warum so böse :p

Es gibt Leute die haben noch mehr im Kopf als Objekte.

Und auch die schönsten OO Programme sind strukturiert prograsmmiert.
Denn ohne Stukturen wären wir wieder zurüch in den alten Basic-Zeiten mit Spagetti-Code.

Strukturierte Programmierung ist Geil. Ob es jetzt unbedingt eine Programmiersprahce sein muss
die sich auf den proceduralen Ansatz festlegt, ist eine ganz andere Frage.

Und die Einstellung "Bei mir kann jeder nach meiner Fasson selig werden" ist auch schon reichlich veraltet

Bashar

PAD: Unfug. Weißt du überhaupt was strukturierte Programmierung ist?

Coda

thx PAD
aber könntest du mir plz sagen was du anders gemacht hast als ich

hat geklappt

PAD

Dazu sind die Code Schnipsel im Forum zu kurz. Mein Verdacht ist das bei die Positionen der break Statements nicht richtig waren und deshalb falsch gewirkt haben

@Bashar Ja den sonnst könnte man so eine Blödsinn nicht schreiben.

Hatte mich nur über meine Vorredner geärgert, und musste das irgenwie loswerden.
Ich stehe weder auf Absolu- noch auf Dogma- tismus

volkard

PAD schrieb:

Hatte mich nur über meine Vorredner geärgert, und musste das irgenwie loswerden.
Ich stehe weder auf Absolu- noch auf Dogma- tismus

sollst nachdenke, wenn ich laut werde, nicht blödsinn labern.
solltest einfach meine argumente verstehen und mir zustimmen.
und jetzt husch, lies was über single exit in pascal und was über exceptions in c++.