for(;;) schleife verlassen

[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

[Bashar]

JFK: Da hatte Jansen auch Recht. Die Frage ist, ob das relevant ist. Strukturierte Programmierung ist im wesentlichen ein Dogma, das Programme fordert, die sich durch Struktogramme darstellen lassen. Das bedeutet im Einzelnen mindestens:

• es gibt nur Sequenz, einseitige, zweiseitige, mehrseitige Auswahl, kopfgesteuerte und fußgesteuerte Schleife (auch eine in der Mitte abgebrochene Schleife, die allerdings meistens verschwiegen wird, weil Pascal sowas nicht hat)
• d.h. kein goto
• jeder Anweisungsblock hat nur einen Eingang und nur einen Ausgang

Das mag vor 30 Jahren wirklich sinnvoll gewesen sein. Aber wie gesagt, es ist ein Dogma. Das eigentliche Ziel war, die Verständlichkeit von Programmen zu verbessern. Wenn das Ziel auch ohne SP erreicht werden kann, warum nicht?

Man sollte dabei z.B. bedenken, dass Exceptions nach der strukturierten Programmierung verboten sind, da sie zu zusätzlichen Ausstiegspunkten führen.

[AndreasD]

Ist richtig, was Du sagst. Und deshalb kann ich nur PAD zitieren:

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

Dogmen haben zu Beginn ihrer Einführung etwas heilsames. Aber nach einer gewissen Zeit verlieren sie teilweise oder ganz ihre Daseinsberechtigung und es schadet nicht, diese über Bord zu werfen. Die Zeiten, wo man noch Struktogramme machte, sind in der Praxis vorbei. Oder man skizziert mit diesen Mitteln nur noch Prozesse und grobe Zusammenhänge.

Ich muß gestehen, daß ich Exceptions auch nicht so wirklich gerne mag und setze die nur dort ein, wo ich weiß, daß es schwere Probleme sind, die üblicherweise nur während der Entwicklungsphase auftreten sollten oder wenn das System ohnehin kurz vor dem Kniefall ist.
Wenn aber irgendwas nicht so klappt, wie ich das von einer Methode verlange, dann kann die ruhig einen Fehlerwert zurückgeben und ich nehme in Kauf, daß 7fach verschachtelte Funktions/Methodenaufrufe wieder rückwärts laufen. Ich empfinde das als deutlich logischer, als wenn ich eine Exception schmeiße und irgendwer wird die hoffentlich irgendwo abfangen...

Kann gut sein, daß ich nicht wirklich in C++ codiere & denke. Aber wie gesagt: wenn etwas verständlich und fachlich richtig ist, so wie es ist, dann bin ich auf jeden Fall dafür, daß so zu machen.

Aber ich schweife wieder mal ab....

[crass]

for und while waren bei ihrer Erfindung schätz ich mal beide nicht dafür gedacht sie als Endlosschleifen zu verwenden. Schleifen die nicht gleich sagen, wo sie mal aufhören sind ja böse.. es is ja soviel feiner brav immer mit Flags zu arbeiten. Dann hat mal jemand gemerkt , daß Flags in Wirklichkeit nerven und man besser die Schleife endlos macht und sie mittendrin breakt oder returnt aber statt das mal einer auf die Idde gekommen wäre die Sprache so zu erweitern, daß es extra für diesen Zweck einen Schleifentyp gibt
zb.

loop
{
   if (irgendwas) break;
}

gibt, muß man sich halt mit billigen Tricksereien a la Parameter weglassen (for(;; ) ) oder die Weiterlauf-Bedingung immer wahr sein zu lassen, aushelfen..besser ist da imo keins davon

[HumeSikkins]

Ich muß gestehen, daß ich Exceptions auch nicht so wirklich gerne mag und setze die nur dort ein, wo ich weiß, daß es schwere Probleme sind, die üblicherweise nur während der Entwicklungsphase auftreten sollten oder wenn das System ohnehin kurz vor dem Kniefall ist.
Wenn aber irgendwas nicht so klappt, wie ich das von einer Methode verlange, dann kann die ruhig einen Fehlerwert zurückgeben und ich nehme in Kauf, daß 7fach verschachtelte Funktions/Methodenaufrufe wieder rückwärts laufen. Ich empfinde das als deutlich logischer, als wenn ich eine Exception schmeiße und irgendwer wird die hoffentlich irgendwo abfangen...

Hm, mir scheint du mißverstehst Exceptions ein wenig. Exceptions sind letztlich auch nur eine Form des "error-" bzw. "early returns". Mit dem Vorteil, dass der Fehlerpfad nicht so sehr den "normalen" Programmpfad stört. Und das sich Fehler nicht so leicht ignorieren lassen.

Wenn du folgenden Code hast (Beispiel adaptiert aus "Exception-Safety in Generic Components" von David Abrahams):

int gunc()
{
    Foo f;
    int result = f.func(); // kann werfen
    // mach was
    return result;
}

kannst du diesen natürlich auch so umschreiben, dass du keine Exceptions verwendest:

ErrorCode gunc(int& result)
{
    Foo f;
    ErrorCode e = f.func(result);
    if (e != NoError)    
        return e;
    // mach was
    return NoError;
}

Programmtechnisch macht das keinen Unterschied. Der erste Code-Schnipsel
ist aber kürzer und hübscher.

Zwar wirken Exceptions auf den ersten Blick häufig komplizierter als Fehlercodes, allein schon, weil man z.B. überall was über Exception-Safety lesen kann, nicht aber über Error-Safety. Das liegt aber nicht daran, dass Exceptions irgendwelche zusätzlichen Probleme hätten. Vielmehr ist "Exception-Safety" ein unglücklicher Name, denn die Prinzipien haben nicht direkt etwas mit Exceptions zu tun. Sie gelten eher generell. D.h. Code der sich im Falle von Exceptions nicht anständig verhält, der verhält sich auch nicht besser, wenn man alle Exceptions durch Fehlercodes ersetzt.

[THE_FreaK]

volkard schrieb:

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

Klar, aber was machst du wenn du in nem case zweig bist? oder hab ich da mal wieder was programmiertechnisches verpasst? ^^#
Im Prinzip ist es doch ne geschmacksfrage, oder? beides müsste irgendwie seinen zweck erfüllen, wobei *ich* denke, das son Flag einfach besser zu erkennen ist.

[volkard]

PAD schrieb:

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

dazu sind destruktoren auch da.
was du da vor hast, wird kaputtgehen, wenn exceptions fliegen.

[volkard]

PAD schrieb:

Ich arbeite in der Testgeräteprogrammierung.
Bei uns ...

lol. der code ist ja c. fehler per errorcode statt exception. klar gehste dabei so vor wie in deinem code. dann sind auch andere regeln zum stil angesagt. andere sprache, anderer stil. ich rede von c++. dort hat man rauszuspringen, sobald ein ergebnis feststeht. c ist wirklich ne ganz andere geschichte und hat hier als argumentbringer rein gar nix verloren. und du solltest nicht den c-stil den c++-leuten aufschwätzen wollen.