for(;;) schleife verlassen

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

[volkard]

PAD schrieb:

Und auch die schönsten OO Programme sind strukturiert prograsmmiert.

die schönsten oo programme sind, was den prozeduralen teil angeht, weitgehend nach den regeln der strukturierten programmierung geschrieben. aber nicht ganz. hält man sich zu stark dran, zum beispiel mit künstlichen flags, wird der entstehende code wieder unlesbarer.
es gibt viele, die das nicht raffen. deren lehrer noch pascal denken. die selber auch pascaldenke haen. dort waren alle regeln der strukturierten programmierung gut und sinnvoll. in basic waren sie schon weniger angemessen.

beispiel:
a) böser hack in c++. verletzt wesentliche regel der sp.

bool istPrim(int kandidat)
{
   for(int teiler=2;teiler<kandidat;++teiler)
      if(kandidate%teiler==0)
         return false;//hier steht fest, daß es keine primzahl ist! also raus!
   //oh, ganze schleife fertig und nix gefunden. ist wohl prim.
   return true;
}

b) "schöner code" nach sp.

bool istPrim(int kandidat)
{
   bool flag=true;
   for(int teiler=2;teiler<kandidat;++teiler)
   {
      if(kandidate%teiler==0)
      {
         flag=false;
         break;
      }
   }
   return flag;
}

was ist wohl leichter zu verstehen? der böse hack, gell? und dieses argument zieht. der standardpfad, es zu entkräften wäre der hinweis auf aufräumarbeiten, aber die müssen wegen der exceptions eh in destruktoren rein.

Denn ohne Stukturen wären wir wieder zurüch in den alten Basic-Zeiten mit Spagetti-Code.

keiner sprach davon, basic zu nehmen. und bite unterschiede basic v2 von vb. vb hat durchaus gute schleifen und mit foreach sorag was, was c++ ernsthaft fehlt.

edit: upd, der code b) ist ja kacke, denn break ist so böse wie goto.
c) endlich "schöner code" nach sp.

bool istPrim(int kandidat)
{
   bool flag=true;
   for(int teiler=2;teiler<kandidat && flag;++teiler)
      if(kandidate%teiler==0)
         flag=false;
   return flag;
}

und dann wird einem natürlich auch gleich für zu unschmachkaft
d) noch ein "schöner code" nach sp.

bool istPrim(int kandidat)
{
   bool flag=true;
   int teiler=2;
   while(teiler<kandidat && flag)
   {
      if(kandidate%teiler==0)
         flag=false;
      ++teiler;
   }
   return flag;
}

[_Stefan]

Wenn ich jemals eine Endlosschleife brauchen werde würde ich niemals for nehmen.
Das sagt einen schon die Logik.
Benutze persönlich genauso niemals break (ist für mich genauso unschön wie ein goto).

[_Stefan]

Wenn ich jemals eine Endlosschleife brauchen werde würde ich niemals for nehmen.
Das sagt einen schon die Logik.
Benutze persönlich genauso niemals break (ist für mich genauso unschön wie ein goto).

[_Stefan]

ups einmal ist keinmal.

[Erhard Henkes]

@volkard: jetzt bist Du aber dogmatisch.

Ich muss volkard aber zustimmen. Seine Idee, "langweilig" zu programmieren - sprich möglichst klar, gefällt mir gut (siehe seinen Kurs, z.B. Nimm-Spiel. Dort springt er zweimal mit return aus Schleifen.).

Es ist doch völlig egal, wie ich eine Endlosschleife bastele. Bestenfalls im Assembler-/Basic-Stil:

Marke:
  goto Marke;

[volkard]

Erhard Henkes schrieb:

@volkard: jetzt bist Du aber dogmatisch.
Es ist doch völlig egal, wie ich eine Endlosschleife bastele.

argumente stehen weiter oben. möchtest du dagegen argumentieren?

Erhard Henkes schrieb:

Bestenfalls im Assembler-/Basic-Stil:

Marke:
  goto Marke;

in basic hat man

do
 print "hallo, welt"
loop

was habt ihr nur alle gegen basic?

[THE_FreaK]

@Volkard
Und wie realisierst du einen schleifenabbruch wenn du in der schleife verschiedene sachen hast die einen abbruch auslösen können?
Ich seh da kaum ne andere Möglickeit als n Flag.
BSP:
Die Verarbeitung von Nachrichten in der WinAPI. mehrere Nachrichten könnten einenn ABruch der schleife zur Folge ham.

Oder hab ich da n "designdenkfehler"

[volkard]

THE_FreaK schrieb:

@Volkard
Und wie realisierst du einen schleifenabbruch wenn du in der schleife verschiedene sachen hast die einen abbruch auslösen können?
Ich seh da kaum ne andere Möglickeit als n Flag.

an verschiedenen stellen kann man doch break schreiben. oder noch besser return. sehe dein problem nicht.

[Floh]

@ _stefan:

wie verläßt du dann schleifen vorzeitig? oder machst du das gar nicht?

[PAD]

@Volkhard Beitrag von 23:28

Sowohl Lösung a als auch lösung b haben ihre Berechtigung.
Ich würde allerdings die Schleife nur bis kanditat/2 laufen lassen, Spart ne masse Zeit.
Aufräumarbeiten sind nicht nur Dinge die durch Destruktoren erledigt werden können, es können auch
längere CodeSequencen sein, die sich mit ganz anderen Dingen beschäftigen (siehe Hardwarenahe Programmierung, Schnittstellen unminitialiseren so daß ich gar keine Destructor brauche) .
Diese Teile von Code könnte man auch unmittelbar ins if schreiben, was aber die Lesbarkeit nicht unbedingt fördert.

solltest einfach meine argumente verstehen und mir zustimmen.

Überzeugen ist besser als Überreden

Nur einfache Lösungen sind gute Lösungen und das egal woher Sie kommen

Mein Bezug zu Basic bezog sich auf die Vergangenheit, diese Art von Basic Compileren/Interpretern kennen die meisten Leute heute nicht mehr. Die "moderenen" Compiler haben bei sovielen guten Sprachen geräubert das es jetzt etwas ganz anderes geworden ist (blos was).
Nur der Name ist geblieben, weil jeder meint in Basic kann ja auch ich programmiern, Hochsprachen I´gitt ba Pfui viel zu kompliziert.

[AndreasD]

Also ich muß Euch eines sagen. Ich hatte vor einiger Zeit mal im BCB-Teil gepostet, daß ich am Anfang einer Methode Prüfungen mache und wenn etwas nicht stimmt bzw. die Methode einfach aufhören soll (sei's, um eine Fehlerkennung ohne Exception zurückzugeben oder um einen im konkreten Fall sinnlosen/unnötigen Aufruf der Methode zu unterbinden), dann springe ich mit einem return gleich zu Beginn aus der Methode raus. Jansen warf mir dort einen Verstoß gegen die sp vor. Das sah ich aber nicht so, weil es für mich eindeutiger ist, daß ich aufhöre und nicht noch 20 Hilfsflags definiere und 30 if-Abfragen einbaue, die dann ein nettes eingerücke geben und man dann gar nicht mehr weiß, wann man durch welche Bedingung durchläuft (stark übertrieben).

Aber gegen ein break in einer längeren for-Sequenz hab ich auch nichts. Wieso sollte ich diese Technik des Schleifenausbruchs verhindern? Wenn ich ein break lese, weiß ich, daß der aus einer switch oder der innersten do/while/for Schleife ausbricht und gut ist. Ein klein bissel Vernunft darf ich ja von anderen Programmierern erwarten, wenn sie sowas lesen. Da ich zusätzlich auch überwiegend kommentiere, was sich tut, ist's sowieso kein Thema.

Zum Thema Endlosschleife möchte ich gestehen, daß ich auch eher zur while-Konstruktion tendiere, wobei man auch genausogut for(;;) nehmen kann. Für mich ist das eine aber so gut oder so schlecht wie das andere. Die Sprache gibt es mir in die Hand und ich kann doch selber entscheiden, wie ich das anwende. Ob das nun von C, Basic, PL1, Pascal oder was auch immer entlehnt ist, ist mir in dem Fall aber grad wurscht. Man muß ja auch nicht alles zutiefst hinterfragen und regeln. Ich sehe da keinen besonderen Sinn drin. Da gibt es sicherlich andere Dinge, über die man sich streiten kann.

[PAD]

@JFK Ist deine Signatur ein Hinweis auf OOP, ganz schön hintersinnig

Was man heute noch nicht weiß,
ist übermorgen möglicherweise schon
total veraltet...

Ich arbeite in der Testgeräteprogrammierung.
Bei uns ist es eine feste Regel daszu erst alle Parameter ausgewertet und überprüft werden, und nur wenn sie alle
richtig sind finden irgendwelche Aktioenen statt. (Also genauso wie du es auch machst)

func1(...)
{
//Auswerten überprüfen
for (a;b;c)
{
  if (error)
   ErrorCode=33;
   flag=FAIL;
   break;
}
.....

 if (PASS != flag)
   return ErrorCode;

//jetzt Settings verändern und Hardware ansprechen

....
return PASS;
}

Da ist mir auch ein Verstoß gegen sp, oop oder ähnliches völlig egal

Nur einfache Lösungen sind gute Lösungen und das egal woher Sie kommen, das Beste wird genommen

Das ich damit natürlich an der Uni mit den jeweiligen Gurus/Dozenten im Clinch liege ist mir klar. Aber mein Studium habe ich vor
Jahren erfolgreich beendet und arbeite jetzt in der industriellen Realität